^ b/c of this, I actually like how MacOS separated app and window switching. It's a bit more fine grained, and I can use either of the two depending on the specific intention.
I always understood the move to Apple Silicon was also for supply chain concerns, and not just technical. I remember reading that Apple would often express frustration at having to align their products' schedules based on Intel's schedules, and there would be a lack of support from Intel in their collaboration -- I could see this is a a valid bottleneck for Apple, and this isn't their first rodeo in processor transitions. Of course, now, their bottleneck moves down the supply chain and will be TSMC, but TSMC seems to be happy to provide whatever Apple asks for, as seen with their large 3nm orders.
So why work only with Intel and not also with AMD. Never understood that. They chose vendor lock in so of course the vendor is going to sit on it same as Motorola did and later IBM. Now they still have vendor lock in except the vendor is internal. From a distance, it looks super dumb, betting that you can do better with an internal project than playing off the established duopoly. I'm sure I'm too out of the know to understand.
One thing to remember is that hardware designs have a much longer lead time than software and significant support commitments since they need to maintain a business relationship for a decade. When AMD started gaining on speed versus Intel, especially for the thermally-constrained systems Apple sells, Apple already had an in-house CPU design team which was doing good work and they were quite familiar with the benefits in terms of roadmap coordination, pricing, and support.
Apple used the AMD chips that didn't absolutely suck: the GPUs (and they still got plenty of criticism for that). AMD's CPUs were not at all suitable for Apple's most important products until the past few years. The first Zen mobile processors were only a year before Intel's 10nm Ice Lake.
Linear Algebra courses in pure math degrees are typically used as a gentle introduction to theoretical math, different from the applied linear algebra courses that engineers and the likes would take.
Just based on my experience with UCLA's pure math undergraduate program (which I assume is similar to other top tier math departments), the listed subjects in the video cover the "core/required" courses of a solid pure math degree. PDE's and differential equations in general are optional electives (edit: usually taken by the applied variants of math degrees).
It should also be noted that calculus is a pre-req for even declaring the major, and hope the video should list that as a pre-req for self-study as pure math.
Just from the top of my head, SKY (SNU, Korea, Yonsei) have pretty significant grade inflation -- probably not as bad as Harvard -- and a cursory Google search supports that.
Back to US schools, I'd like to see some analysis on the correlation between the proportion of # of GE courses for a program and that program's grade inflation levels. Also, compare public vs private schools' grade inflation. Schools in general have a strong incentive to send their students to internships and post-grad programs at prestigious IB firms, consulting firms, law schools, grad schools, and etc; and I wouldn't be surprised if private schools tend to have more lenient policies in relation to grade inflation to boost that goal.
Doesn't each new generation of the workforce have a sense of entitlement and privilege previously unheard of? Workplace expectations change every decade; just b/c this expectation of working remote is new doesn't mean that it's irrational.
Many tech organizations genuinely do not reap the benefits of working in-office like some other fields might.
If I were an automotive design engineer, being in-person in the company's design studio would make sense; if I'm developing a highly abstracted and distributed messaging system, what office resources would I utilizing?
From my experience, in-office interactions are not necessarily more productive than online interactions. In fact, when a team has a good grasp of the remote-working tools, we, more often than not, end up communicating more succinctly and effectively.
"Life is hard," sure, but no need to make it any harder than it needs to be.
Anyone who has done software engineering on a reasonably sized "2 pizza team" would have to acknowledge that it's easier to do software engineering if you're all co-located at the same physical location in the same timezone several days a week.
The fact that we _can_ get work done remotely doesn't mean it's the most effective way for software engineers (which make up most engineering teams these days) to work.
Eh, I probably wouldn't bat an eye, unless if you had a reputation of being culturally insensitive. If you wanna play it safe, you can postmark "... and yes, I agree, it is a bit gimmicky."
I don't think game devs on average want to be closer to hardware. Game engine devs, sure; but the average game dev would like to use a higher level language that interfaces to the c/c++ stuff that game engine devs are pushing out.
