dasyatidprime

I agree with an overall thrust of “C++ is overcomplicated and has many moving parts and a lot of implicit stuff happening in the background that makes it difficult to understand”. But I do want to briefly note that Lisp environments have macro expansion steppers for a reason too.

I think “indoctrinate” is more likely.

Aren't you talking about how expressions are evaluated in #if there? An expression form that shows up in a macro that is then embedded in normal C code just becomes part of the C code that could potentially get evaluated with C rules at compile time; it's not inherently evaluated at preprocessor time.

if table --warble farble; then :; else table_ec=$?; echo "Garble warble farble! :(" >&2; exit $table_ec; fi

Works in dash/bash/zsh at least; not 100% sure whether the behavior of $? on the command in an if test is mandated by POSIX and/or portable. Note that you can't replace the empty then-branch with a negated condition because the negation also eats the return code.

Also, absolutely correct propagation is essentially impossible (but usually not useful anyway), because some errors might be unexpected signal exits or inability to find the command in the first place, and those will get punned onto other nonzero exit codes. I forget the exact conventions OTTOMH but generally they're in the high half (≥128).

They wrote “if and why”.

If there were definitely no legal encumbrances, surely they'd want to keep shipping the version with the proprietary codecs in, because that would make them a superior option for users who need those? AFAICT someone upstream thought that having the toggle to avoid patent issues was important, which if true nixes the idea that VA-API just gives you an automatic unencumbered route and you don't have to worry about it after that.

I'm not really sure what actual claim you're making regarding the relevance of “pro-patent views”, but I might interpret it as something like “Red Hat is more likely to play it safe, whereas less IBM-enculturated distributions are more likely to bet on interpretations that let the users take on the risk”. Which I think is probably true; for instance, https://www.reddit.com/r/linux/comments/xqn20n/comment/iqbmv... describes how other distributions chose differently and moved to re-enable the proprietary codecs by default. (Some of them seem to be based in friendlier jurisdictions, mind. I'm not completely sure where BMD is, and I'm not sure how much it matters given they want to sell worldwide, but their full corporate name resolves most strongly to Australia: https://opengovau.com/business/30098098287 and Australia doesn't seem to exclude software from patentability: https://www.ipaustralia.gov.au/patents/what-are-patents/what...)

Anyway, if that's what you meant, I don't think that distinction is nearly as applicable to the situation with Resolve. BMD isn't a producer of a Linux distribution containing a broad variety of stuff, where “users happen to do stuff with the open source software we provide that violates some patents” can maybe be waved off as not their responsibility. BMD is very obviously directly operating in the commercially-distributed professional video tooling market, so codec licensing will be something they have to deal with as a keystone part of their business. Adding something to their software to actively enable people to do professional-style encoding for those codecs without the patent licenses would be playing with fire.

That doesn't sound right to me at all. I'm pretty hazy on the specifics of VA-API, but I wasn't under the impression that the graphics hardware carries 100% of the decode implementation nor had codec licenses attached to it, and this Phoronix article from 2022 describing Fedora having to back off from having accidentally shipped H.264 via VA-API without appropriate licensing seems to be evidence in the direction I expected. https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API

Do you have any information on how the actual patent licensing is set up for Vivaldi? I wasn't able to find much on it, though I see the note in https://wiki.archlinux.org/title/Vivaldi that it “automatically downloads” the relevant files, which is at least suggestive that they can't just redistribute the binaries normally. The other closest thing I was able to find was https://github.com/chromiumembedded/cef/issues/3559 which describes a specific proprietary_codecs option in CEF, which is not quite the same thing but ought in some sense to be related… the way they describe having to set ffmpeg_brand=Chrome normally for that to be available doesn't sound promising?

I would be moderately surprised if whatever arrangement is going on there allows full use of the codecs for video editing software and not just for consumer decode of Web resources.

This is one of the the cases where “the language model won't necessarily respect IP law” is really relevant. Individual users may be able to get away with this because they're too scattershot to sue, and users in some jurisdictions may actually be fine regardless, but broadly, the patent licensing around things like H.264 is not something BMD can afford to ignore. AFAIK the biggest reason Google was pushing WebM in the first place was because they, a huge corporation, were balking at being under the thumb of the MPEG LA!

I appreciate that it can be confusing for users that patents can still apply to techniques where implementations exist that are both libre and gratis from a copyright perspective, but this has been an issue for Linux-adjacent software distribution for ages—like, see how Debian used to put certain stuff that was encumbered by patents in the US but not in other jurisdictions in special “non-US” repository sections, that sort of thing. It's not Black Magic's doing that the codec space is like this. I wish people wouldn't make so many mocking assumptions sometimes.

I'm not an experienced video editor, but I don't think the bulk of video editing involves generating new content on the fly except for narrow cases like adding titles, which is where an AI would easily be able to lean on scripting the existing tooling. There's a ton of grunt work involved in fixing up cuts and figuring out where everything is and so forth.

And to bring up a likely reason: my impression is that H.264 and AAC still have active patents that apply to the major implementations, and those are not licensed gratis for all uses, and that applies more heavily to the encoding side. Raspberry Pi used to (and might still, I don't know) offer add-on license keys to unlock certain video codec support for what I assume was a similar reason. A lot of individual Linux desktop users just do their small-scale FFmpeg runs under the radar, but commercial software delivery is different.

With proprietary operating systems, the commercial entity behind the OS can negotiate for licensing. Some commercially-associated Linux distributions have efforts in similar directions, like Fedora for instance has some special secondary-repo stuff around H.264 support, but that's at minimum much more fragmentary as a target for an application developer concerned with the legalities.

My impression is that one of the social effects of domain names being cheap and easy to get (at least among many vaguely technologist-adjacent cohorts) is that failing to invest in a 2LD for a new thing winds up seen as tacky, sort of an “if you weren't willing to invest enough to put a cover on it then what does that mean for whether it's any good” thing (you could see it as a counterparty good-faith deposit versus attentional costs if you like). In some cases this goes down to the level of individual publications. Additionally the way social technology has wound up around URLs seems to mean that both longer URLs and artificially shortened ones wind up losing secondary reach in unpredictable ways. I'm not that fond of this trend but I can see ways it winds up making sense in context. I don't know how widespread it is.

That doesn't follow. I'm pretty sure they're talking about the effect of nominal wage stickiness: you're not constantly renegotiating your rate, so when there's fluctuations in relative value, it matters what unit the original number is denominated in. Compare with the case of a US expat being paid a steady salary in USD and converting to the local currency to make purchases, if you want an example with a similar mechanic but very different intuitive feel and practicalities.

(I'm not sure they're right about the overall effect though.)

A single SQLite ‘connection’ can be ATTACHed to multiple database files (which appear as separate prefixed schemata, but you can do things like joins across them) and it seems to work properly if some are read-only and some are not!

For those interested in the history of alternatives to port numbers: Chaosnet[1] in LispM/ITS times used names for describing which service was being requested. On the TCP side, a spec for requesting services by name has existed since 1988: TCPMUX[2], using a short initial handshake after connecting to port 1. Just never caught on AFAIK.

[1] https://chaosnet.net/protocol#application_layer [2] https://datatracker.ietf.org/doc/html/rfc1078

TeX uses -- (double hyphen) for producing an en dash and --- (triple hyphen) for an em dash, and that's pretty darn longstanding and well-established. And FWIW, the English writing conventions that I learned use em dashes as punctuation without an adjoining space—like this—but allow en dashes surrounded by spaces as an alternative – like this – so I frequently see spaced double hyphen used as the ASCII equivalent of dash punctuation and interpret it as the latter. I've never personally heard of double hyphen for em specifically, only either as en specifically or as a sort of ambiguous whatever-dash.

There is an ISBN URN namespace, but I don't know whether anyone maps it to anything. https://www.iana.org/assignments/urn-formal/isbn

I don't have experience with the Fedora version specifically, but forum/email bridges tend to run into problems with differing expectations of the medium. This is even more true if it's not clear from the beginning that other users are experiencing the same conversation completely differently. For a viscerally annoying example, imagine someone posting “bump” to a mailing list.

I use a layout with an AZERTY-style shifted digit row for coding (and for everything else). A quick check of one C++ codebase I've been working with shows ~20× as many instances of digit-row symbols as digits (18× for QWERTY digit-row symbols, 27× for those in my layout), though C++ is unusually symbol-heavy. A couple of ECMAScript repositories show 3× or 10×. On some Common Lisp, digit-row symbols are 5× as common as digits for my layout and 22× for QWERTY (almost entirely because QWERTY parentheses are terrible). I don't expect to see a lot of code where numeric literals are more common than type modifiers and operators and such… most of the times numbers are being manipulated in code, they're not being typed in directly as digits but going through comparisons and arithmetic and such, and that's symbols.

FWIW, the common utility library Serapeum offers ‘op’ which it claims is from GOO, which is quite similar as a short positional function utility macro without being a reader macro that has more potential for character clashes: (op (> _ 0)). (But don't let that stop you from recreating it if you wanted to do so for educational purposes!)

That's the source! That's the one I remembered but couldn't find! Thank you.

Having skimmed the article, I think he's correct about the most common use of macros (by far the single most common type of macro I write in CL is a body-to-lambda transformation, though being able to tweak the sugar makes a difference too), but then I think he kinda equivocates in implications between “80% of the usage” and “80% of the impact”. I also think Ruby DSLs cover a big chunk of that last gap (and it sounds like you might agree with me). Part of the classic Lisp Curse is that easy access to advanced metaprogramming indirectly increases social fragmentation, but part of the Blub Curse is that lack of access to advanced features causes people to have to solve the same dumb problems over and over again, so you lose efficiency and create different fragmentation. Having fancier metaprogramming functionality require a bunch of rigamarole but be possible to work through when you need it might plausibly hit a sweet spot in the middle there.

Notably, Yukihiro Matsumoto took substantial inspiration from Lisp while designing the Ruby language. You can see historical Lisp terminology in the Ruby interpreter sources (at least last I checked, which was a long time ago), like the use of “Q” to refer to a dynamically typed datum that can be stored in a cell.

(Hah, I just looked around a bit more, and Wikipedia cites an archived mailing list message that I don't remember seeing before: https://web.archive.org/web/20181027195101/http://blade.naga... I remember at some point Emacs Lisp specifically being cited as an inspiration, but I might be confabulating that, I didn't find a source for it.)

Also, here's a fun paragraph from the opening comments of quail.el (lightly reformatted):

> [There was an input method for Mule 2.3 called ‘Tamago’ from the Japanese ‘TAkusan MAtasete GOmen-nasai’, or ‘Sorry for having you wait so long’; this couldn't be included in Emacs 20. ‘Tamago’ is Japanese for ‘egg’ (implicitly a hen's egg). Handa-san made a smaller and simpler system; the smaller quail egg is also eaten in Japan. Maybe others will be egged on to write more sorts of input methods.]

> So what I usually do is compile a list of melodic hooks from popular songs my students enjoy. Every so often, we’ll play them and let the student try to pick them out on the piano or their instrument of choice.

As someone who had ongoing formal musical training from childhood through university, I can attest that multiple teachers used a similar technique, focusing on finding a group of commonly-heard melodies such that the first intervals encountered in them cover as much of the set as possible.

Haven't tried the game yet, but looking forward to checking it out later to see if I can offer it to some of my friends who want to learn music better!

The copyright to the Outlook binary isn't owned by the users either, even if they're running it on local hardware. The Opus 4.8 weights are (we assume) the same between users, but the conversation/tooling state is not shared between them by default. I prefer to route around this construction myself, since I do think there's some ontological slippery-slope potential, but from a lexical perspective I think “my” is a perfectly defensible abbreviation in context.

> it's much easier for everyone involved to ship a server binary like Valve has done for ages

This is drifting some from the original specific topic toward the broader conflict, but, not for everyone involved, surely? Will the audience run your server binary, under normal circumstances? Or will they say “Wow, you couldn't even be bothered to put up some basic servers for free? Jeez, you're saying I have to set up a whole account somewhere else and pay them just so I can have a multiplayer game, or set up weird-looking technical shit on my computer that might expose me to hackers? Nobody else asks me to do this, what is this bullshit”? Of course there are intermediary options here (one of which I describe below), but those don't necessarily let you do the “we didn't want to be in the hosting business” plan straightforwardly, so you might still have to take on a lot of the fixed planning costs.

The incentive gradient among consumers tilting so hard in the direction of indefinite active support becoming table stakes seems to be a core part of the vicious cycle here. “I shouldn't have to set stuff up” implicitly cedes control; if they're not doing the coordination, then someone is, and that someone gets hidden responsibility and power without compensation or effective voice, which is an unstable combination by default. This is a similar issue to what happens with convenient, centralized, subsidized social media and chat platforms.

Minecraft is actually an interesting borderline case here: the player license authentication and name/appearance binding is all centralized, and that could suddenly go away and leave everyone in the dark, but individual world servers can be run independently and there are a number of third-party hosting businesses based on this. Microsoft later felt compelled to offer Realms as a first-party means of setup, but IIRC those do take a recurring fee so it's not in the same unstable zone. But then we have a separate issue where, as far as I can dimly tell, a lot of people started expecting “game companies do the work to keep us safe on Their Platform” as, again, table stakes, and so they implemented non-repudiable digital signatures in chat to allow people on non-centrally-hosted servers to still report each other's chat messages to central moderation, which I must assume is another ongoing cost. (In the modded world there are mods that strip this.)

Most of the problem with browning is the physics: it requires temperatures well above boiling, but the default microwave absorber is water which will tend to saturate around boiling temp. But physical cookware design can be used to make it work: the article I linked prominently describes the use of a browning skillet with a tin oxide coating on the bottom that can safely absorb large amounts of microwave radiation and get hot enough to brown foods.

So partly due to that, I think if you wanted to do full robotic cookery with a microwave beyond the TV-dinner stage you'd still need control over the other objects rather than just switching the magnetron. Stirring for even heat distribution is another thing.

And then it's separately interesting how, in a really skew way, “deliver heat using RF energy” came back from a different angle with the rise of induction stoves!

You might both be interested in https://malmesbury.substack.com/p/my-journey-to-the-microwav... regarding the history of microwave cooking (not mine). The microwave oven wasn't known destined to be relegated to lowbrow cookery from the beginning, even if that's how it turned out from our perspective, and some of the more advanced techniques developed for it fell out of use.

That's called CESU-8. https://www.unicode.org/reports/tr26/tr26-4.html

Not what anyone was talking about. Training corpus ≠ inference engine.