I just extracted the self-reported completion times data from the Architecture 2001: x86-64 OS Internals #OST2 beta class students who filled out all 10 entries, and it looks like the following. Some thoughts below…
1) This was originally created targeting about 2 days (~14 hours after subtracting lunch ;)) of in-person delivery. You can see a *few* students could do it in that time, but most needed more time. This is why I really like that I can now let students learn at their own pace
I don’t really think anyone’s well-served by the 1-size-fits-all approach of dragging students through a class in less time than they need to understand the material. If someone needs 62 hours to finish a class, I say give it to them!
2) There wasn’t any particular guidance on whether to include or exclude time spent just fiddling around (as is recommended at various points), so it’s possible multiple students took longer than shown (some students commented which way they did it, but I deleted those comments
while normalizing the data)
3) Back to point 1, I don’t really know how much of the > 14 hour times can be explained by me having inadvertently expanded the content while remaking it, e.g. by adding a few more and deeper explainers on some topics, or by making optional material which people just took anyway
4) Some students have asked for posting approximate completion times on the sections of classes, and I’m reticent to do so. A) because as shown above, averages of course flatten out distributions, which are more interesting to look at, B) I don’t want to commit to posting
distributions for sections unless it could be automated (which I don’t have time to do (this is a volunteer opportunity for anyone who wants to grub around in the Open edX database ;))) and, C) because there’s no “approximate completion times” on learning in the real world
5) FWIW more than 18 students did complete the Arch2001 private beta, it’s just they didn’t all give me usable data ;)
6) A BIG THANKS TO ALL THE ARCH2001 PRIVATE BETA TESTERS WHO HELPED MAKE THE CLASS BETTER, AND SUBMITTED FULL DATA!
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Thread: This would perhaps be a good time to point out that while it’s absolutely true that Windows’ UEFI SecureBoot is intentionally not designed to defend against physical presence, that’s actually an improvement I shot for with Mac SecureBoot, first on T2 and then M1
I termed the security goal “P != X” meaning mere physical possession *in and of itself* should not equal code execution. Rather, possession must be combined with knowledge of an administrator password before you could disable that critical security feature.
I was able to shoot for this because Macs have a couple things going for them: 1) the first user which is set up is an administrator user by default 2) all Macs have a “recovery OS” (originally an HFS partition, and then an APFS volume), which has always been digitally signed
Check it out for more about the first-in-the-world work @coreykal & Rafal Wojtczuk have done for UEFI DMA protection and UEFI sandboxing of PCIe Option ROMs
Thread: A while back I was asked to add SGX attack papers to the timeline. That seemed reasonable to me, so I started collecting them...and then got distracted before I had worked through cross-references and such...
In general I'm not super interested in capturing the SGX/SideChannel category of papers, because they're mostly academic papers, which already do a good job of citation. So you can always just look at the end of the latest few papers to find most of the previous papers...
Whereas, the stuff I normally capture is conference talks / blog posts, and the non-academic security community does a *terrible* job of citing related work, hence why it needs collection