Cold ketchup on hot french fries is one of life's great joys, though.
816 karma · joined April 14, 2013
This works even without the alias, by the way: by default `git whatever` will search your path for `git-whatever` and execute it.
There are, of course, stylistic norms, and a lot of those norms are shared across lots of kinds of Western music. The thing I'm pushing back against is a misconception I see a lot that people who teach music theory are arbiters of quality in music, and that music that doesn't "follow Bach's rules" is somehow less good than music that does. (That misconception is probably well deserved, because that is how music theory was presented for a long time. I think that has changed, though, and that you'd be hard-pressed to find someone in the field that holds that position these days.)
If so: that's not really what I'm saying at all! Even in courses that focus primarily on, say, Western common-practice harmony (as many basic undergrad theory courses do), you're likely to find a much broader variety of music being taught than just the Bach chorales. That's partly because the field as a whole has been moving away from strict adherence to the traditional canon, but also more basically it's just good pedagogy. That is: most music that students play isn't going to be four-part homophony, and so learning to do harmonic analysis of string quintets or saxophone quartets or lead sheets provides a much stronger grounding about how harmony works in real music -- even if you circumscribe harmony quite strictly as "harmony as deployed in Western common-practice music betwen 1700 and 1850."
Disclaimer: I left the field and have been employed full-time as a software developer for more than 5 years, and pedagogy isn't an area of the field I follow closely. A good recent example is the open-access textbook Open Music Theory (https://viva.pressbooks.pub/openmusictheory/); perusing the examples there I think will be a good demonstration of the breadth of both styles and composers that's pretty representative of current pedagogy, even without radically altering the aims of the undergraduate music theory curriculum (which is also happening).
To use your analogy: composers are inventing music in the same way that normal speakers invent language. I don't think I'd describe new variations on language as "inventing linguistics," though, as linguistics is the in-depth study of language (and as such, "inventing linguistics" is something done by linguists, not by language speakers). But language is not linguistics, in the same way that music is not music theory.
But also: the majority of academic music theory at the moment does focus broadly on the Western tradition. That's changing, I think, but a quick scan of recent articles in Music Theory Online (https://www.mtosmt.org/issues/issues.php) reveals quite a broad spectrum of music, most (not all!) of it is from the Western tradition.
Bach's chorales were functional music for the Lutheran church, and to the extent that they form any sort of "rules" in music theory, it comes from the fact that they have been used to teach harmony for a long time (since at least the 1940s, as evidenced by this article). The reason for that isn't so much that they're prime examples of Western common-practice harmony, but rather that they have a homogeneous texture that's easy to use in classrooms, because they're easy for one person to play at the piano or for students to sing.
Recent music theory pedagogy has largely been moving away from the reliance on Bach chorales to teach harmony, especially as music theory has taken a broader perspective on what music we should be studying anyway. Studying the Bach chorales is just fine if you want to know about how Bach used harmony, but there's a whole lot of music in the world, and there's no meaningful sense in which Bach's music intrinsically defines a set of rules any more than Mozart's or Clara Schumann's or AC/DC's or Meredith Monk's defines a set of rules.
There's not a timeline for that right now, nor clear consensus on what exactly will be worth a version bump or how much backcompat between 5.x and 7.x there will be going forward. It's being actively discussed, though; the Perl Steering Committee (formed a couple of years ago) meets weekly, and discussion on p5p (the language development mailing list) is still fairly active, though admittedly much less so than in years gone by.
Many of the things the author cites are good about Perl are, in fact, good about Perl. But if you're writing new software in 2022, you should probably pick a language with a future, and that language is probably not Perl.
And in times like today, it's so nice to be able to say "hey, $person_working_now, could you deal with fastmailstatus.com and Twitter please?" and the engineering staff don't even have to think about it!
Without getting into too much detail: we were limiting some HTTP methods, but unintentionally blocked REPORT, which DAV clients use to see what’s changed.
This isn't strictly true (that you can have as many as you want), because SPF has a (IMO) very silly hard limit of 10 DNS lookups per record. From RFC 7208:
> Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
We see this not infrequently at Fastmail, when customers report DMARC validation problems, and the answer turns out to be that they've got too many includes in their SPF records, so SPF always fails.
In the backend, there is no difference between labels mode and folders mode; all of the changes are in the UI. There are no IMAP attributes or keywords (they're poorly supported by third-party clients); any email message can appear in more than one mailbox, where "mailbox" means "folder" or "label".
On disk, mailboxes are stored as UNIX directories: all copies of the message (i.e., in all folders/labels) are hard links to the same inode. Over IMAP, each can have its own metadata (\Seen and \Flagged, for example), and they'll probably appear as separate copies (depending on how your client decides to do things).
As you say, JMAP has this built in: each Email object has a MailboxIds property. When the web client (or your own bespoke JMAP client!) fetches emails for one folder/label, and then you click to a different folder/label, the client doesn't have to download that message again, because it already has it in its local cache.