The Emacs welcome screen links to a tutorial, a guided tour, and manual, all of which are inside Emacs. I would say its help functionality is potentially its greatest strength.
Dude, incredible work. I've only discovered CL in the last couple of months and everything I learn and discover brings me so much joy after being solidly disillusioned with programming after a decade-ish career. The first page of your tutorial cracked me up and a quick glance at CLOG has blown my mind. I can't wait to dig into it all.
Microsoft's interview loop was the easiest I've ever had, it's the only job I've had where I've felt my ethics challenged, and my org's leadership was comically ruthless.
You joined a good org and that's awesome, but I believe you can just as easily join a bad one at Microsoft or a good one at Amazon.
Yes, but they left out explicit murder-for-hire charges in the indictment for that trial. They filed a separate indictment with those charges in a different state which they dropped after the first trial ended.
It's not exactly the same but I see a pattern of using an accusation to influence a trial without intending to prove it.
Why would I spend any time stepping through lines I'm not interested in? I set breakpoints on the important parts and let the program run until a breakpoint is hit.
I stop at a breakpoint only after another breakpoint is hit all the time. You set the first breakpoint and run the program. It gets hit and pauses, you set the second breakpoint, then resume.
I'm just not getting how print debugging is the better experience.
This is the only argument for print debugging I can understand. Given the debugger experience I've had at every job in the last 10 years (IDE-driven, set breakpoints in editor, inspect state visually) it's mind-boggling that anyone thinks print statements are superior, but getting that experience can be frustrating depending on your tools and environment.
FWIW my experience debugging Python in VS Code required no setup and I've encountered zero issues.
Why would one step through the whole program? Use the approach you describe for print statements, but for breakpoints instead. Set them, inspect the relevant state when one is hit, then resume execution until the next is hit.
Yeah, but what's the cost? RAID5's striping with parity is a cost-saving approach compared to mirroring. If you can afford to mirror all your data that will always be the better option.
If you can afford to purchase 2x the disks for RAID10 you will certainly get better performance and availability. RAID5 is an approach that gives you lower cost in return for slower writes and less fault tolerance. Everything is a trade-off.
No, e2scrub_all is a filesystem-level check which serves a different purpose.
mdadm scrubbing is in various states of broken across major distros. It used to be that each distro had their own cron-based scrubbing scripts. At some point mdadm introduced its own checks using systemd timers and there have been bugs upstream and in packaging.
I only noticed because I'm preparing to upgrade an old home server and carefully double checking everything. I'll probably end up grabbing one of the old cron scripts and setting it up manually. Very disappointing.
I like to think most people in our field are naturally curious, so make sure your environment doesn't stifle that attitude. Hold group learning sessions for new technologies, code reviews, and so forth. As a senior explicitly seek out advice and explanations from newer colleagues even if you can figure it out on your own. Hopefully they'll end up feeling comfortable doing the same.