114 karma · joined March 12, 2018
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)?
What's the history of this first project I've been assigned to?
Who are the most important customers, or types of customers?
What's the risk tolerance (unless you've been told Move Fast Break Things)?
Things you usually can't ask directly, but need to learn quickly:
Is this a meritocracy? If not, what other factors matter?
What types of actions are perceived as throwing a co-worker under the bus?
Is most of my job to figure out what my job is (i.e., exploring how I can contribute most effectively)?
Cleaning up /var/tmp on a timer is relevant to this academic environment (desktop-based research computing):
1. Each Debian machine is used by only one graduate student, but students do not have root access.
2. Today, /var/tmp is the only persistent local directory where the student has write access ($HOME is on a network filesystem backed up by the university).
3. Within the student population, there is strong institutional memory that /var/tmp isn't backed up by the university and isn't extremely robust (e.g., RAID), but also that nothing there is automatically deleted.
4. Students use /var/tmp for hundreds of Gb of data from simulations that take days or weeks. $HOME is too small and too slow for this.
5. In practice, less than 1% of students lose data through disk failure, accidents, etc.
6. A much larger fraction of students will lose data when sysadmins, who didn't get the memo about the /var/tmp change and thus haven't addressed the ingrained institutional memory, deploy new Debian machines.
7. Some of the students who lose data won't graduate on time.
Avoids writing everything twice: you don't need to name the data fields both in the base URL and in the query string
If there are several parameters, writing everything twice may make the URL longer than one physical line in a text editor
The ? and & characters need to be quoted in most shells
The _ characters are sometimes hard to read if the entire URL is underlined
Names with api_json don't make it clear whether the request body must be sent as JSON, the response will be JSON, or both
"lavabo" sounds too close to "lavatory" - and this has even stronger negative connotations. For Americans, at least, a "lavatory" (and thus perhaps the entire "lav-" word stem that means "wash") is never something that you have in your home. The term "lavatory" would most commonly be used at a school, but may also often be used at any other non-residential building. For Americans, "lavatory" almost always means a room that you visit to eliminate your bodily wastes (it doesn't only mean where you would wash afterward). Because anyone in the building can use the lavatory, it's usually not thought to be fully sanitary.
Potential customers will hate both of these, but "lavabo" is sure to kill U.S. sales.
https://learn.microsoft.com/en-us/azure/active-directory/aut...
"(i) General rule. No national bank, and no director, officer, employee, or agent of a national bank, shall disclose a SAR or any information that would reveal the existence of a SAR. Any national bank, and any director, officer, employee, or agent of any national bank that is subpoenaed or otherwise requested to disclose a SAR, or any information that would reveal the existence of a SAR, shall decline to produce the SAR or such information, ..."
A bank might not want to aggregate data, within one IT system, if part of the data has the very unusual property that a subpoena must be declined.
This isn't a perfect solution but your "support their devices with security updates for a reasonable amount of time" is a non-starter. For example, suppose I'm designing a doll for the Christmas 2024 season. The doll uses the Internet because it's an AI product that converses with young children about the latest STEM news. I don't know how long it'll be used: maybe my eight year old daughter will just find it boring, or maybe she'll physically destroy the doll because she disagrees with its opinion on the Riemann hypothesis.
I can't afford to maintain firmware beyond January 2025. If I have to commit, I'll just never release the product, and children will potentially have worse learning outcomes forever. But I am willing to have my 1.0 firmware send beacon frames to cooperating routers, announcing that my combination of product ID and patch level is a8217a61-09de-4b1e-8a99-b6fbc180cdce, and please blackhole me if this is a dangerous version. This requires more engineering to work effectively, but please don't stifle innovation by small IoT vendors who cannot commit firmware-maintenance resources to a product with an unknown revenue stream.