Throw some items in your cart and enjoy all the emails reminding you to check out, look at similar items, share with your friends, and use discounts before they expire!
> A neat trick I was told is to always have sleep statements in your code. Just a few sleep statements that you can delete in cases like this. This won't fix the problem, but will buy you time and free up latency for stuff like slow algorithms so you can get faster code.
I just upgraded to a 49" curved display because it lets me view everything I need _for the current task_ at one time.
One virtual desktop is Messages, Slack, and Outlook for all my comms needs.
Another is IDE & browser for development work.
Another is todo list, planner, notes, and browser for task management.
Having to constantly swap app between browser, email, IDE, slack, etc is interruptive. Being able to switch to a single-focus desktop with everything visible is much more productive for me and reduces context switching.
What's your viewing distance? I currently have a 32" at about 80cm or so. Did not like the 34" as it has actually less vertical space despite having more area technically.
My viewing distance is one-arm-length (kinda close), when I raise my arm my fingertips just touch the screen. Definitely closer than my previous monitor, as you need to sit within the curved-screen radius to be in the sweet spot.
Looks like it's 32:9 aspect ratio - it's this Samsung, it was on sale last week for $800: https://a.co/d/0f884LPO
As an article that was here recently claims, every verification you do in a chain increases the total time of your work by an order of magnitude. So, it's only work optimizing any productive task if you already removed most verifications.
Now, some people claim that you need to improve the reliability of your productive tasks so you can remove the verifications and be faster. Those people are, of course, a bunch of coward Luddites.
Apparently I made note of this in my laptop setup script (but not when this happened so I don't know how long ago this was) so in case anyone was curious, the jar file was compiled with java 16, but the nix config was running it with java 8. I assume they were both java 8 when it was set up and the jar file upgraded but don't really know what happened.
No it doesn't.
If the content of a url changes then the only way to have reproducibility is caching.
You tell nix the content hash is some value and it looks up the value in the nix store.
Note, it will match anything with that content hash so it is absolutely possible to tell it the wrong hash.
Not having a required input, say when you try to reproduce a previous build of a package, is a separate issue to an input silently changing when you go to rebuild it. No build system can ensure a link stays up, only that what's fetched hasn't changed. The latter is what the hash in nix is for. If it tries to fetch a file from a link and the hash doesn't match, the build fails.
Flakes, then, run in a pure evaluation mode, meaning you don't have access to stuff like the system triple, the current time, or env vars and all fetching functions require a hash.
Buildkit has the same caching model. That's what I'm saying.
It doesn't force you to give it digests like nix functions often do but you can (and should).
Of course, you also don’t get a refund until you file.
And you usually have to do all the same work to know whether you owe or not…
reply