His top students were capable of entirely understanding Scheme within a day or so (but not capable of entirely understanding all of Python and all of PyPI). He wanted students to be even better than that. He wanted them to lead productive and resilient collaborations even when they didn't or couldn't entirely understand the small parts.
Given a day, top students can understand enough of Python to write enough code to get the point about how programs rely on abstraction and composition.
(Of course, the latter part of the course, describing the implementation of the runtime, would need considerable rethinking.)
Yesterday, you saw the first 30-minute segment. Today, you arrive at the multiplex, and are informed that the three 30-minute segments (1, 2, 3) are starting shortly on screens A, B, and C. However, you are not told the mapping of segment to screen. You are asked to select a screen, and choose screen B. You are then informed about the status of either screen A or screen C: that status may be that it will play segment 1 (from your perspective: a duplicate) or that it will play segment 3 (from your perspective: out of order). Finally, you are asked whether you will be watching screen B, or the other, unrevealed screen. (If you don't actually watch your final choice, you're banned from the multiplex forever.)
Is this harder (e.g., not solvable at all) compared to the Monty Hall problem, because segment 1 is merely an annoyance, but segment 3 is a spoiler (permanently impacting your enjoyment of the movie)?
For "With your threat model in mind, they should identify opportunities to add new test cases," one common reason is that security engineers are shared across a large company and it may be very expensive for them to learn the different testing frameworks used on many different projects. Also, independent review (without any exposure to developers' conceptions about what should be tested, or why, or how) may be economically justified because outcomes of security bugs are sometimes much worse than outcomes of many categories of ordinary bugs. Other reasons may include that the security engineers want to run a test that can't be expressed in your testing framework without a huge change to the framework, they may want to develop their test cases adaptively such that most of the tests turn out to be useless and the cost of capturing every test under version contol may be very high, they may want to run tests from a commercial testing product for which the license does not allow bulk copying of the tests into a customer's testing framework, or (if they aren't in-house engineers) their business model is that they won't tell you every test that was run unless there's an associated defect finding.
> ... one common reason is that security engineers are shared across a large company and it may be very expensive for them to learn the different testing frameworks used on many different projects
That's where the partnering part of the approach I'm proposing comes into it. The security engineer isn't off there by themselves trying to figure out it, but is working with somebody who's already familiar with the existing code base & testing frameworks.
> also, independent review (without any exposure to developers' conceptions about what should be tested, or why, or how) may be economically justified because outcomes of security bugs are sometimes much worse than outcomes of many categories of ordinary bugs.
Economically justifiable perhaps, but that doesn't necessarily mean we shouldn't explore better ways of achieving similar outcomes.
> Other reasons may include that the security engineers want to run a test that can't be expressed in your testing framework without a huge change to the framework, they may want to develop their test cases adaptively such that most of the tests turn out to be useless and the cost of capturing every test under version contol may be very high, they may want to run tests from a commercial testing product for which the license does not allow bulk copying of the tests into a customer's testing framework, or (if they aren't in-house engineers) their business model is that they won't tell you every test that was run unless there's an associated defect finding.
Yeah, this'd be interesting to experiment with. The accepted model of security testing being separate allows this uncoupling of tooling / process, but .. perhaps the outcomes of a more-tightly-coupled testing methodology would be better?
I don't think any of these points are blockers, more just factors to consider or trade-offs to balance when exploring alternative, less separate, approaches.
We added ChatGPT Operator to UI testing, starting soon after it launched. It's only used as an extra testing step on top of everything we had previously used. A quick summary is: on the plus side, it sometimes gives us a much faster feedback cycle. On the minus side, it sometimes dives headfirst into advanced UI features, and can't find a way to backtrack when it makes a mistake there.
The TOCTOU is relevant (without suid) if someone can quickly make the right prediction of the tmpname2 value that's generated by the PRNG used by mkstemp, and create a symlink with that value before gunzip is executed. After calling mkstemp, the code should use the returned file descriptor, and thereby eliminate all TOCTOU risk. However, on (perhaps?) most devices that would realistically use atop, the PRNG works well enough that that prediction would fail.
https://newscience.org/nih/ suggests that the higher indirect rates at private research institutions may occur because "universities do subsidize research out of their own pockets."
Really interesting read as an outsider. A lot of inside baseball, but my impression is that a ton of the indirect costs do fund the institution building that has happened at universities. This creates a cycle of more = more as indirect costs ratchet up and up. Surely there should be scale in indirect costs (e.g., the more money you get, the lower your indirect costs as a percentage?) In fact, I think we see the opposite in the data?
