When you conceive of Teenage Engineering first and foremost as a design firm that incidentally tends to release neat synthesizers, so much of what they do will make way more sense.
840 karma · joined July 20, 2009
I took econometrics on a dare once. You can't just describe a real-world change as an exogenous shock in general.
I get told "no" a lot.
I schwätz noch d'Muddasprooch.
I studied to be an actuary, but I spent 15 years writing systems software. I am cursed to live a life being intimately familiar with both Excel/VBA and Linux kernel internals.
"I HAVE NO TOOLS BECAUSE I'VE DESTROYED MY TOOLS WITH MY TOOLS." https://www.usenix.org/system/files/1311_05-08_mickens.pdf
Capitalism kills markets.
By losing its grip on shared norms, mores, and folkways, society inadvertently builds the very thing that libertarians fear most: an omnipresent, heavy-handed state. However, it's worth mentioning that this doesn't happen because of a socialist conspiracy, irrespective of one's understanding of what socialism actually is; rather, it happens because a society without internal and cultural self-regulation must necessarily invite a tyrant to step in and govern by his application of law just to keep that society from tearing itself asunder.
topcolor: aaaaaa
pronoun.is/they/them
[ my public key: https://keybase.io/nrr; my proof: https://keybase.io/nrr/sigs/mUwfAxr143F7sGzkfa65fPWi1OnSD3zhNyaE0UdmROA ]
If we take your 10% base rate to be disease prevalence, that gives us 100 sick and 900 well.
Of the 100 sick, something with 90% sensitivity should get me 90 true positive tests and 10 false negative tests.
Of the 900 well, I should expect to see for a test with 90% specificity, what, 80 false positives and 810 true negatives? if I did my arithmetic right?
Somewhere, the industry went all-in on Kubernetes, and I have zero desire to touch most of the resulting software stacks. We sold folks hard on complexity being necessary, and Kubernetes makes it very tempting to go ham with it.
This kind of thing is almost always a weighted coin toss: with sensitivity or specificity alone, you only have two possible outcomes (present/relevant, absent/irrelevant), and the thing that changes is the probability distribution of those outcomes.
Combining the two gets you the full four: present and relevant; present and irrelevant; absent and relevant; and absent and irrelevant. Taking the uniform distribution, they're all 25% likely, but the idea is to find a probability distribution that makes the "present and relevant" and "absent and relevant" outcomes more likely.
Since I myself don't work in a clinical setting, I simply hadn't considered that the clinician would want to exercise discretion in pre-screening for specificity before ordering the test in order to get there. Oops.
Thanks for clarifying.
(While I'm here, in case folks are lacking the statistics background: specificity and sensitivity refer to the probabilities that a test will return with a negative test result in the absence of a condition or a positive test result in the presence of a condition respectively.)
Most of the "promising" tests I've seen tend to be something like 80% sensitive and 20% specific (testing for Lyme disease comes to mind), which makes them no better than flipping a weighted coin. The fact that this Alzheimer's test beats that feels like a big deal on the probability merits alone, and I can't think of basically any other tests that do that. (Serum cardiac troponins maybe?)
The rub comes in when you want to pull that content out to render it in a format that isn't meant to be camera-ready, like a Web page or an e-book. TeX, even with Leslie Lamport's LaTeX macros, doesn't give you an ergonomic mechanism for marshalling out the semantic structure of your document to reuse elsewhere.
You're left parsing the TeX yourself, and that sucks.
reStructuredText isn't itself a typesetting language. It's meant to be something of an interposer between the semantic meaning of what you're writing and the thing that does the typesetting. The hope is that it, unlike something heavily constrained like Markdown, gives you the tools to capture that semantic meaning and transform it into something that can be typeset.
Like, the goal isn't to throw out TeX. The goal is to be able to target TeX as a typesetter along with Web browsers and e-book readers and even things like GNU info and troff without having to rewrite the content wholesale to fit each one.
Cheshire, CT, also happened to be an AUTOVON site, which carried with it military and national security significance. This is why it was hardened against nuclear attack, including the air handling augmentations, decontamination shower, gamma ray detection equipment, and so on.
That there makes me feel a little less confident in an MVS 3.8j patching effort.
To your note about a hypervisor though: I did consider going this route. I already find VM/370 something of a more useful system anyway, and having my own VM/XA of sorts is an entertaining prospect.
Having a simulated 3033 running at 10+ MIPS is pretty nice though. (:
That's before we get into the (lack of?) empirical data. I'm finding it hard to come up with any citations that offer an existence proof of a Laffer curve for real, actual public finance systems. The Cato Institute and Brookings have things to say, but they're encumbered by policy goals. Ebrill, also encumbered by policy goals near as I can tell, urges caution. Espanhol's master's thesis concludes that a Laffer curve doesn't exist in its investigation of corporate tax rates across the Eurozone.
So, frankly, I'm keener just to throw out the academics here.
That's also before we get into what debt is and how it works. It isn't a call option: the persons, fictitious and natural, to whom the US government is indebted cannot exercise those debts on a whim in an effort to get paid. They have a maturity schedule. What matters to these creditors (and all creditors more broadly) is that there's faith that their debt instruments will eventually fully mature. For natural persons, that's likely decades from now. For fictitious persons like governments, that could very well be on the order of centuries.
It's for this reason why I also reject the appeal to Jerome Powell's authority: he doesn't express a concrete reason why he expects the faith that those persons, fictious and natural, have in the federal government to erode to the point where default is some notion of imminent. Does he expect the executive branch to stop payments suddenly? Does he expect that the tax base will collapse in the very near future? (Malthusians in particular are fond of crying the latter, predicting widespread famine.)
Furthermore, that's all before we get into taxation and how it works. It's a sticky subject academically, even after you peel away the conflicting policy goals. Is taxation revenue? Is it a constraint on the money supply? Is it economic dead weight? The answer to all of these is, "It really depends." One model says one thing, and another says something else, and there isn't a whole lot of real consensus on which one fits best where. (Economics, it turns out, is one of those social sciences, which means that most experimentation is thorny unless you abandon ethics. When all you have is models...)
The thing that matters at the end of the day is that someone (maybe you!) will cheerfully accept my greenbacks for what I reasonably feel like they're worth, and as long as that remains the case, I'll happily render unto Caesar until we finally find a way to kill him for good.
Unfortunately, Scrum, a major framework that's built around those ideas, is also kind of, uh, syndicalist. It requires a lot of worker control and self-organization to pull off well. XP ("extreme programming"), another framework that's more prescriptive about the engineering practices than the project management side of things, also suffers from this problem.
None of this stuff is a priori true.
"Furthermore, you can’t time box that sort of software development into sprints in any way that’s not artificial and arbitrary." You absolutely can. Sprints are by their very nature artificial and arbitrary. They're there to establish a reporting interval, with the ideal report being "we have something to deliver" and the pathological report being "we pulled the andon cord because the facts changed in a profound way, and we need to regroup." Whether or not a sprint results in the ideal has the probability of a coin toss, and if you're wildly on either side of that, consider changing the rules of your sprint framework: make the interval longer/shorter, do less/more, take on less/more risk, whatever.
There's zero reason to sit down and decree, "A sprint is two weeks. We must deliver something every sprint." That isn't at all how any of this works. In fact, that's how to make the framework fight you and burn you out.
For systems software, the deliverables can very easily be formal specifications, integration tests, SDK examples, and prose describing the results of design feasibility experiments, all in addition to the runnable systems software itself. Documentation also fits here. Lots of other things do too.
(As an aside: If you can, pull your SDK examples from your integration tests. This will help your documentation not be stale.)
It's also worth noting that stories also fit in well, but they must be handled correctly. A story is a starting place for a conversation with the stakeholders, not itself a deliverable. It's a placeholder so that your product owner can do some digging and figure out what the stakeholders need so that they can turn those needs into a product backlog item with acceptance tests for the thing that ultimately gets delivered.
Oh, also, if a product backlog item makes it to the current sprint without acceptance tests, that's a beach day. (Or perhaps a day to get caught up on support tickets while the product owner straightens that out, but going to the beach and doing some stunt kite flying is way more fun and comes highly recommended.)
It could very well be that design feasibility experiments change the facts, to the point where a lot of rework is needed. That's fine. The entire point of the exercise is to try to clamp down on the risk inherent in rework (if not eliminate it entirely, but that's often impossible): by stopping the current sprint in its tracks, it communicates to everyone that extra care is needed in order to proceed. The analysis of what went wrong and how to resolve it can happen outside the sprint framework; it's probably inappropriate to get too meta in the product backlog.
To quote Fred Brooks: "Plan to throw one away." You will anyway. You'll likely do it a lot. That's honestly probably best for systems software. Just make sure this expectation is communicated clearly and actually planned!
Also, kill your bug tracker. This is especially true for systems software and other kinds of software that provide a platform for other folks to run code: bugs in your software will amplify the bugs in your users' applications. If you need to, let the bug kill the sprint; it's better to let it happen now than to have to do a lot more rework later.
As a corollary, let the bug cause the facts to change so profoundly as to require you to re-plan your product backlog. This is fine! This is the entire point of the exercise. You've identified risk to the product, and the framework is in place to give you the tools and rituals to handle it.
(While I'm here: you're hopefully not re-planning your product backlog at the end of every sprint. That's ideally at most a once-yearly activity, but if you're finding that your management is requiring you to re-order things every few weeks at their whim, guess where you just identified the risk to the product.)
I hope this helps.
(That said, there may have been an X server brought in at some point, but don't quote me on that. That's the least of anyone's problems in undertaking a CDE port though.)
The accusatory use of the second person implies that you're in my head enough to know that I'm trying to win an argument. It's patently untrue; I want to be loudly wrong so that I have more than merely a snowball's chance in hell of garnering understanding here.
If you have corrections to offer, I'm receptive to them.
The Wikipedia link has it as its first reference, but it's honestly worth linking directly here. I highly recommend trying to get someone to give you a TSO/E account and picking up HLASM.
Yeah, they've actually sold less than that, but in context, it's still very much a "let's throw it at the wall and see what sticks" kind of thing. It also nonetheless fits how Apple communicates their product vision in new areas.
We need to remember that Europe is the continent that gave us extractive colonialism. A player always knows their own game.