Well, true, but tyres wouldn't make it a double distance, it's not that simple. The case isn't clear, if course, but the claim says that the odometer tried to reduce the range after it got out of the warranty period.
Not saying anything about the merit of the case, just the the claim itself sounds interesting and that if true, you can't wave it away with "you changed tyres".
Fucking hell, that site a million partners who all have "legitimate interest". I've clicked on like a third of them and then gave up. I don't need their shit.
asd
Like others here, I'll almost always do:
I'll frequently also enable Sharpen and either Filmic RGB or Shadows and Highlights, depending on the style I want.
I'll sometimes crop the images.
When I actually want to do manual editing, it'll mostly be a small tweak in the RGB levels followed by Colour balance RGB module. I'll also adjust exposure partially, via masks, and similar other tweaks.
Very rarely ill want to heal something with Retouch.
When I'm really having fun (and time), I'll just go tinker with everything else just to see what happens. It's rare that I have the time, though.
yeah, traceroute might hint at that, if this is what is going on.
I will perhaps be nitpicking, but... not exactly, not always. People get their shit hacked all the time due to poor practices. And then those hacked things can send emails and texts and other spam all they want, and it'll not be forged headers, so you still need spam filtering.
left-pad as a service.
Much better integrated refactoring support. Much better source code integration support. Much better integrated debugging support. Much better integrated assistive (but not ai) support.
Vscode can do many things IntelliJ can, but not all, and many of them require fiddling with plugins.
Usually, JB is also faster (if your dev machine can run it, but in my experience most devs have beefy machines).
I don't know what happened, but since 6.2 rolled out on Fedora a week ago, I've had several bugs. At the very day I updated, I had two outright crashes. It happened a few more times since. My keyboard shortcuts don't work any more. Window layout behaves...odd (haven't pinned it down yet).
Just all-around messy upgrade. Am I the only one with problems, though?
One thing to add that I haven't seen is that for big projects, there's often nobody that could understand it all. People either get their individual components it they understand how stuff interacts, it's very rarely expected that new people in the project, even if very experienced, can just understand everything at once.
What you said that maintainers know every single fob is very frequently not the case at all! But since they get the big picture, they know in which part to look, and with their experience, they'll know what to look for in that part, it may seem to you like magic. It's not, it's just experience.
Don't get discouraged though!
Getting into big open source projects as a junior -level can be difficult, but often isn't that hard - a lot of projects often need help and will take anything they can get. And if your experience already partially aligns with what you're getting into, even better. If you reach out and be upfront about it, you'll usually get pointed in some way.
Now, you seem to only have worked on your own, with smaller code bases. That means, you don't have a problem of code organisation. So you can't understand a solution if you don't know what the problem is.
So how would you go about it?
My suggestion is to maybe get the. 10,000ft overview. Also, understand the project workflow. Projects usually have specific ways of doing things - how to build, test, run things. Try to figure out how to build and run the software on your own. If you make it, that's a great step!
Then dig into one specific component/module/part. After a bit of study, you may be able to understand that component and find a simple thing that you can change about it. If you get this far you're golden, you're doing more then a majority of users that software.
Now if you're interested, you can dig more, or reach out to devs, saying what your experience is and how far you got, and ask them if you can help. And take it from there.
I think it is a bit more than that.
You point out two things:
So, now, obviously if you wrote the "fuck it", then well, you fix it. If you found the DNS library problem - find a better lib or something.
But if you take the stance "fuck it, there's always something", you don't even have a chance of finding out. If you had a test suite running 10 seconds, and suddenly it's up by 10 more, you would notice. If you had tests running for 10 minutes, you would not.
If you had a webapp or something that always opened "fast", then suddenly it gets doubly slower, you'll notice it. But if you already started slow, you won't notice (or care, or both), when it gets even worse.
I think that's the point of the article. If we all dug in and fixed a little bit, eventually we'd have fast apps or tests or whatever. If you accept that things suck, you'll make it tripply worse. It is a conscious effort to be fast.
It's 12, looks good to me.