a everyday joe would do
Go to work, work, go home. Wait for the end of the week/month for their next paycheck.
Most people already have more then a dollar and more then 24 hours to earn money. If schemes like that really worked then why would so many people do anything else?
I saw some people using Arch to learn the inside out of Linux, but I’m afraid It could be to challenging.
It will be challenging but IMO give it a shot if you think it is something you might want to do. No harm in trying really. If you mess it up or find it too hard or whatever you can always install something else afterwards. It is not like you are stuck with your first choice forever. The only thing you will lose is a bit of time and will gain a better understanding of things even if you cannot make it fully work.
I don't agree that arch is not a beginner distro - it is a DIY distro that requires a lot of reading and willingness to learn and understand things. The arch wiki is an excellent resource for anyone (on any distro IMO) and well worth reading. If you are OK with that work then it makes a fine distro for anyone, beginner or not. It is not a distro for many people - again does not matter if they are a beginner or not. It is for people with a particular mindset. One that you might change over time or as you grow and learn more overall.
No harm either if you decide it is not for you. Play around with a few distros and try to find which one works best for you. There is really no one best distro. Just a lot of different things that appeal to different people and the only real way to find out which you like is to try them out.
Your code creeps to the right very quickly. This makes it hard to read and follow. Best to avoid that and avoid too many levels of indentations. Typically when you have:
if condition_1 {
if condition_2 {
if condition_3 {
actual_work();
}
}
}
You can refactor it to:
if !condition_1 {
continue; // or return or some other way to short circuit
}
if !condition_2 {
continue; // or return or some other way to short circuit
}
if !condition_3 {
continue; // or return or some other way to short circuit
}
actual_work();
This generally makes things easier to follow, you can check all the validation conditions at the start then forget about them for the actual body. With the nested ifs you generally need to keep them in mind until you know there is no else block or anything else which just adds to the cognitive load while reading the code. Especially in your case with some code and come continues below it means you need to jump up and down between the start and the end trying to understand what code gets run in different conditions.
However in your case you are using if lets which makes things a bit more complex but you can now (in edition 2021 since rust version 1.65) do this instead of the if let:
let Some(command) = message.get(0..6) else { continue; }
This is known as the let-else syntax.
You are also throwing away a lot of errors with this approach. This can be annoying to the user if they format things wrong or do something unexpected you just ignore the message - which could make it seem like the bot is not working. Instead of telling the user they did something wrong and should try again which is much more user friendly.
There is a major usability issue with the bot as well if you ever get more than one user trying to interact with it at once. They will share the same guess and attempts and when one person wins those will be reset causing a huge amount of confusion to the second player. You likely want to store the guesses and attempts in a hashmap on the channel id (I think at least since this is private messages each PM will have a unique ID? If not you need to base it on something unique to that interaction).
Your unwraps on sending the messages could also be an issue. If there is ever a problem with the connection your application will crash losing all in progress games/data. You may want to handle that a bit more gracefully and attempt to reconnect when that happens (ie have a loop around the connection code that keeps trying to connect with a delay between each attempt before trying to get messages in the inner loop.)
Any surface that looks/feels flat will be good enough for this use case, no need to find a bit of glass. Most table tops will do. You might need something better for flattening heat sinks, but for 3d prints you don't need to be that accurate. The plastic will deform far more under light pressure then the difference in any relatively flat surface you can find.
If you have one then there is no harm in using it - but also not need to explicitly look for something that flat. Any table will likely be good enough.
It looks like the gap is a whole perimeter missing likely caused by the infill being printed first? Or something else inside stopping it from being flush on the outside. This might not help now (unless you can separate the parts without damaging the outer perimeter) but before gluing it up it would have been best to get some sandpaper on a flat surface and sand the whole top flat until you have one complete outer perimeter. Or cut away the infill so the outer perimeter is the highest point.
If you cannot separate them without damage to the outer perimeters then you have a few options. First you could deform the plastic near then seam to cover it up. This can be done by heating the seam up with a hot air gun or hair dryer and pressing the layers together to close up the gap. You would really want to be gentle with the heat, just enough to let it start plasticity deforming with moderate/light pressure but not enough so it deforms under its own weight. Too much heat will also start to melt the surface edges of the layers rounding them over and making them look shiny which can look very obvious as well. So you really need to take it slow and apply as little heat as you can until it is just soft enough to deform.
The other options are to fill the gap. This can be done with any old filler but requires lots of sanding and painting afterwards. Or you can try to fill it with more plastic. You can use your printer to print small lines to give you something the right shape to fill the gaps, then it is just a matter of gluing or melting it in place. Super glue/CA glue will not be a good option here as it tends to leave white smear on 3d prints if you get any over spill which is very likely with a small gap. There are some glues designed for PLA that don't do this but I have never tried them myself. You could also heat the patch first until it can deform and press it in quickly though this can be tricky to do quickly enough before it cools and may not stick in well. There are also solvents you can get that dissolve the plastic and let it weld together, best way to use that is to dip the patch peace in it and press that into the gap trying to get as little on the print as you can - any spillage will start to dissolve the layer lines smoothing them over and making them look shiny.
Each of these does require some skill to do well and are easy to mess up making the print look worst - so i would try them out on some scraps first. Though you can always opt to use any filler and sand/paint the model after but that requires quite a bit of work to make it look good but is the only real option that you can keep going until it looks good.
From an attacker perspective you would do a quick scan to find open ports, then focus on those ports with more expensive/slower scans to find out what is running on those ports. If everything reports open then what ports do you focus on first? So not so much that actually open ports are less interesting, but that actually open ports are harder to find among all the ports.
I don't see why this would help. More likely there are two different teams/people working on either side separately from each other. I bet the windows work involves a lot more work on Microsoft's or the chip manufacturer's side than valves.
(I don't know why jamstack has taken over that site, but the list itself seems to be intact.)
Not really taken over, more just a rebranding. Both are owned by netlify, started off as a list of static site generators you could use with netlify (aka all of them they could find) but then they just rebranded the site and gave it a fancy name like you have with all the other web stacks you have these days.
It is talked about in the hashmap docs:
By default, HashMap uses a hashing algorithm selected to provide resistance against HashDoS attacks. The algorithm is randomly seeded, and a reasonable best-effort is made to generate this seed from a high quality, secure source of randomness provided by the host without blocking the program.
The default hashing algorithm is currently SipHash 1-3, though this is subject to change at any point in the future. While its performance is very competitive for medium sized keys, other hashing algorithms will outperform it for small keys such as integers as well as large keys such as long strings, though those algorithms will typically not protect against attacks such as HashDoS.
Basically, if the attacker has control over the key inserted into a hashmap then with a simple hashing algorithm they can force collisions which results in the hashmap falling back to a much slower linear lookup. This can be enough to stress a server and slow down all requests going through it or even cause it to crash. So a lot of effort is made in the default hasher to mitigate against this. There are faster hashing implementations out there if you are not worried about this that you can opt into. But the default is to be secure.
What places are those?
But then I don't really like to have much else in mod.rs other than mod declarations and pub use.
You can always inline the mod.rs contents in its parent module and have one fewer file overall. Not every module needs to be in its own file.
But generally when working in an IDE I don't like to see a bunch of mod.rs files in the tabs as it just makes it harder to jump to the right one.
No. But only because I switched to helix. I have used vim for a lone time before that. Only having vim on a system is fine. Far worse is only having vi. Which is almost like vim but missing a lot of useful things.