keithwinstein

FWIW, the arithmetic in that example also has a glitch. For the "Mobile" "Control" case, 100/3000 is about 3% rather than 10%.

(FWIW, DVDs use MPEG-2 program streams, not transport streams. Both MPEG-2 part 1 systems streams, just different kinds.)

I think originally from SLAC! https://www.slac.stanford.edu/vault/collvault/greylit/cgtm/C...

One thing that would be fun to know is, e.g., "If the LLM answers question X correctly, then what's a minimal-sized set of things we could remove from the training set and cause it to get that question wrong?" I think with current methods this would be pretty expensive to find out, but, in principle I'm guessing it would be pretty illuminating.

I'm a big fan of Nate Silver, but I think this idea that he "predicted N/50 states correctly" in 2008 and 2012 is mostly a myth.

(1) The website doesn't "predict" a state when it reports that the probability of (e.g.) an Obama victory in Florida is 50.3%, which I believe is what 538 assessed in 2012. If you think that a state's probability distribution is 50/50 between Candidate X and Y, and the outcome is Candidate X, obviously you don't get any points for a good prediction. You didn't make a prediction. And if you say it's 50.3% probability, it's essentially the same situation. You didn't make (much of) a prediction. Which is okay!

(2) In terms of Brier Scores or entropy scores, which compare the probability with the outcome and give more "points" the stronger the prediction was made (vs. what actually happened), FiveThirtyEight's predictions are generally just middle-of-the-pack compared with other websites and mechanisms of aggregating these polls. (See, e.g., https://web.math.princeton.edu/~sswang/Wang_Origins_of_Presi...) There's no strong evidence that 538's predictions are much better or worse than other reasonable ways to weight and aggregate the recent polls that anybody else might come up with.

(3) And... almost everything that tries to quantify the accuracy of the predictions is talking about the state of the 538 website ON THE MORNING OF THE ELECTION. But that's probably the least useful day to be looking at FiveThirtyEight. By then, you can just wait a few hours and get the actual results. :-) The predictions that are really valuable are the ones that are made some time in advance, e.g. one or two months.

But (a) it's hard to directly measure the "accuracy" of a prediction like that, because... things change and we can't rerun the universe, and (b) it's not like the model is somehow time-invariant to be able to measure the accuracy indirectly by proxy; there are various "time until election" factors included in these model itself, the dynamics of the election itself probably have a "time until election" dependency, AND the website operators, including 538, are generally manually tweaking the model parameters or behavior in ways they don't always disclose as the election evolves.

So basically... it's hard to say. I think 538 has done great work, and in general it's incredibly useful to have a consistent world model that you can rationally update to discuss the effect of recent news. The FiveThirtyEight political models are as good as any for that! But I don't think there's much strong evidence they're better.

Opus does support adaptive bitrate audio and in basically the same way; with the reference encoder, you can use OPUS_SET_PREDICTION_DISABLED to create a stream access point.

Loudness management isn't really the purview of the decoder/compressed format itself; the article describes using MPEG-D DRC which is, at least in principle, independent of the choice of xHE-AAC vs. Opus. To be clear I have no idea how companies do dynamic range compression in practice; in the Web setting, maybe via stuff like https://developer.mozilla.org/en-US/docs/Web/API/DynamicsCom... etc.?

Argh, I really wish we could implement the tail-call proposal in wasm2c (while preserving the straightforward transformation of Wasm functions -> C functions), but it seems like it's going to be one of the tougher proposals to handle.

The C committee voted 8-7-8 against including mandatory tail calls in C23 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2941.pdf), mostly I think because of a lack of implementation experience.

LLVM has everything needed via the musttail marker, but the musttail attribute in clang is a lot more restrictive (it enforces that the caller and callee function signatures are the same).

It might theoretically be possible to get more flexibility plumbed through to clang, but then I'm guessing getting GCC on board would be a huge job too. :-/

I may be missing something obvious here, and I'm not a Python expert, but isn't this "get rid of all the emojis, except for one I like" code snippet completely wrong (despite the article's assertions that "it works fine," "the LLM used a neat hack," etc.)?

It seems to always just erase the file, because it declares `keep_emojis` to be a list of one element (`keep_emojis = ['¯\_(ツ)_/¯']`) and then goes USV-by-USV through the file to check if the encoded/decoded coded char is "in" keep_emojis. And there's basically no way that any single char can be. So the output is always empty.

If we wrote it like `keep_emojis = '¯\_(ツ)_/¯'` instead, then it would be a little closer, but in that case the program ends up preserving all non-ASCII characters (including all emojis), because these characters become the empty string after emoji.encode('ascii', 'ignore') and are therefore always "in" the keep_emojis string, so they never get replaced.

The explanation also doesn't make any sense, where it writes: "In the above code, the assumption is made that any ASCII character that cannot be encoded using UTF-8 is an emoji."

That's silly, because every ASCII character can be encoded in UTF-8. It also doesn't correspond to what the code is doing -- what it's really doing (I think) is testing for USVs that can't be encoded in ASCII, but then throwing the char away no matter what.

And, of course, the vast majority of non-ASCII coded characters in Unicode are not emoji, so this is not really a good way to satisfy the user's request. The roundtrip through ASCII seems like a bad idea -- if the user wants you to preserve some emojis while getting rid of most emojis, converting to ASCII (where there are no emojis) doesn't seem like it will be helpful.

Of course it's amazing that ChatGPT is already good enough to produce something close enough to fool venture capitalists into trusting it without trying the code, and these techniques will doubtless continue to improve.

This is awesome! This kind of extreme low-power application was the original reason I wanted Mosh -- I always thought it would be awesome to have a wireless (hand-cranked?) laptop that could run SSH and would only consume energy when (a) a key was pressed [to update the locally generated UI], or (b) it wanted to fire up the radio (on its chosen schedule, e.g. <1 Hz) to retrieve an update from the server of the "ground truth" UI and reconcile that with the local prediction.

I'm much less familiar with the financial model in the humanities, but I don't think your information is correct. (What's your source?) Across the whole university, Stanford's minimum salary for graduate research assistants this year is $12,054 per quarter (four quarters per year), and $12,522 per quarter when serving as a teaching assistant. (https://gfs.stanford.edu/salary/salary23/salary_tables.pdf, and here's what the financial package looks like for a PhD student in, e.g., education: https://ed.stanford.edu/admissions/financing/doctoral)

I'm definitely not telling you to go get a PhD in English/history/education/theater for the money, but if you did, my understanding is that the salary you could expect here is around $48k-$49k a year (+ health plan). I don't think any PhD student is earning less than half the amount I cited.

When you say "A large percentage of Stanford PhD students work at least one additional job," if you mean TAing, then yes, that's true -- I think every PhD student has to TA at least a few times, and more depending on how well-funded their program or advisor are and whether they have their own fellowship. (Regular faculty also have to teach on top of our research responsibilities.) But if you mean some outside-Stanford job, I don't think this is common.

To give one data point, at Stanford CS this year we're paying PhD students $64,110 a year plus fully funded health insurance and tuition, but that figure comes with some caveats:

- A chunk of your money will go towards a Stanford-subsidized dorm room or apartment

- Even beyond housing, the cost of living around here is not cheap

- You may not love Stanford's student health plan, in which case if you're over 26 (and can't be on a parent's plan), you're looking at paying for your own health insurance via the ACA market or otherwise

- To be making the full $64,110, you need to have advanced to candidacy (generally this is 3rd-year students and later) and stay for the summer with a "full-time" [90%] RAship. Many students do summer internships in the industry instead, in which case you're probably making way more money.

- Even with recent economic pressures, this is still much less than you can probably make in the industry, and for some subareas of CS, much much less.

I think the summary would be that if you're in a place where you have the luxury of mostly just needing to support yourself, and your health needs are well-met by a student health plan, you can afford to get a PhD here and focus 100% on it and enjoy a reasonable "student+" lifestyle for the 6ish years that will take. (Or a better lifestyle if you take summers to intern in the industry.) There's still a huge opportunity cost. The people for whom this doesn't work are often people with families to support (e.g. children and/or a partner without their own source of income) or other demands on their time or finances.

(I took two tries to get a PhD, but the second time was great!)

Signal has done a lot of nice work on building a UI that conveys what nerds/paranoid people want to know for private messaging (e.g. "Your safety numbers with so-and-so have changed") while still providing a usable app. But for the most part, the threat model of "private messaging" is one that software can defend against pretty well; everybody understands that when Signal provides "privacy," they don't mean in the face of an adversarial receiver who wants to share the message with the whole world.

For a service like "messages that the receiver can read offline but the sender can later delete [or that auto-delete after 24 hours]," I'm curious to see how they handle the UI when the threat model is harder to defend against cryptographically, because it depends on software that isn't acting as a user-agent. Are they worried about people running rogue clients that save every message (or about screenshots?)? If so, how do you do a good job communicating to the nerdy/paranoid user that deletion is not guaranteed? Or does everybody already understand that auto-deletion is best-effort and shouldn't be treated as on par with the strength of assurance that Signal provides for privacy?

Thanks for this analysis! To me the risk of bearer tokens seems bigger than just "at-rest storage"... My experience is that the security perimeter effectively ends up including every script or other piece of client software that wants to run Git or has access to the channel where the bearer token is entered. (How would you enforce that your credentials manager will only give the bearer token to some particular trusted HTTPS client software that is talking only to GitHub...?) You have to worry about the token getting logged in a debugging log, etc. And, when I give somebody an account that's authenticated with a bearer token, I'm always nervous maybe their hygiene is not so great and they'll end up accidentally pushing the token somewhere publicly visible. AFAIK you don't really have this attack surface when the credential is a private key stored in a hardware token or, at worst, a software agent that only keeps the decrypted version in private memory and only agrees to sign individual challenges.

On the question of HTTPS MITM vs. SSH MITM, I agree that the HTTPS PKI makes a MITM less likely than the (prevalent) use of TOFU for SSH authentication, but I don't think the risks (or what "MITM" means) are the same. If there's an HTTPS MITM when client authentication is via bearer token, the intermediary can steal the client's token and masquerade as them forever. If there's an SSH MITM when client authentication is via public key, then the intermediary can give bogus data to the client and can get data from the client, but to the best of my knowledge I don't think a true application-layer "MITM" is possible (barring downgrade attacks) -- the intermediary can't spin around and authenticate to GitHub, pretending to be the client. The session ID is part of the authentication scheme.

I agree this seems to be the currently in vogue practice, but I am confused by it!

SSH keys are public-private key pairs, where the private portion can live in a hardware token or software agent that only signs individual challenges and never exposes the private key. (It's possible in theory, although admittedly not common, for the user agent to limit approvals to a particular repository using the techniques in https://github.com/StanfordSNR/guardian-agent . It would be nicer if GitHub would enforce granular permissions on SSH keys!)

If I understand right, HTTP access tokens are... bearer tokens where I have to handle the plaintext (so I can transmit it to GitHub) every time I want to use it? I agree it's nice to have GitHub enforcing more granular permissions, but even so the trade really doesn't seem worth it. I may not be getting something here.

I can't speak to every PL venue, but all four places that csrankings.org lists for PL are double-blind these days (PLDI, POPL, ICFP, and OOPSLA).

For the most part, sure, but at the margin I'm not sure the "best paper" can be completely well-defined within its four corners, independent of the author. E.g. the reader might rationally care (to some degree) about what a paper says about the future of the field. If an underfunded non-famous researcher describes marginal preliminary results by pursing some approach, that's one thing, but if my very successful colleagues at Berkeley/Washington/Tsinghua or Google/MSR/Alibaba publish a paper that's like, "We have gotten pretty excited about this technique for a bunch of reasons, some quantified but some more conjectural, or qualitative, or just more difficult to measure so not done yet, but here are some interesting preliminary measurements that should whet your appetite, and because of who we are, our track record of success, and our many grad students/researchers digging for gold, we'll probably find more to report in due time" well, am I wrong to be a little more interested in the second paper on the grounds that I'd like to keep up with the field?

(You might also reasonably believe that the job of an editor or program committee is to assemble the most edifying program or issue when considered as an ensemble, rather than each paper individually.)

I also don't think it's completely crazy to consider to a tiny degree what the reader "wants," separate from their true interest in an omniscient sense. When you click around on the Internet, do you only read the "best papers"? Probably not. This is similar to why the New York Times (and Hacker News) don't use 90% of their word count to remind readers to eat healthy, stop smoking, maintain friendships and regular activity, sleep regular hours, and give away most of their money to buy malaria nets.

Double-anonymous/blind reviewing is completely standard in most areas of computer science, e.g. networking (SIGCOMM, NSDI, IMC, HotNets, MobiCom, MobiSys), systems (OSDI, SOSP, USENIX ATC, HotOS), security (Usenix Security, S&P), machine learning (NeurIPS and ICML), graphics and HCI (SIGGRAPH and CHI), and at least some top-tier theory conferences (like FOCS).

So I think most computer scientists would agree with the article's conclusion that double-anonymous reviewing, while flawed, is better than the alternatives. I don't think I've done a non-anonymous submission in 10 years, and as a reviewer, usually I don't have a strong guess about who wrote the paper (and when I think I know, often I turn out to be wrong). It's a little annoying that this news article in Nature Magazine ignores the longstanding widespread prevalence of this practice in a conference-driven (but... we like to think important) academic discipline. :-)

But: (1) I don't think the big benefit of double-anonymous reviewing is that a lousy paper from a Nobel laureate (or, from CMU/Berkeley/MIT/Stanford) isn't let in unfairly. To me the big benefit seems to be that reviewers have to review every paper as if it might be from their friends or a famous person, and consequently have to review each paper with due care and try sincerely to understand its contribution, which maybe they wouldn't do if they knew it's from some random place/author they've never heard of or don't think highly of. I think the way it affects judgment may be more in equalizing time/effort spent to read and understand a paper (and the generosity you give a paper because "maybe" it was written by your friend or somebody you respect), rather than a straight-up bias towards liking whatever the faculty at a famous university are writing about this year.

(2) While I do think it's true, and a good thing, that double-anonymous reviewing helps "marginalized groups of authors who often struggle to have their work see the world" as the lead researcher says, we should probably acknowledge that authors are not the only beneficiaries of a scientific publication. The interests of the reader matter too -- the journal or conference has some duty to serve them. On the margin, maybe some readers would be more interested to learn what Albert Einstein is thinking about these days, or would like to see a well-balanced conference program that includes a good talk by a known-provocative speaker, instead of one more random (but adequate!) paper from a nobody. I'm not saying we should give a huge weight to this -- it's fine to make people eat their vegetables, but, I don't think we should act like scientific publication is only to give authors a line on their CV and the readers' preference is 100% irrelevant. A scientific journal shouldn't exclusively serve the authors. (Other kinds of media care way too much about what the reader wants, e.g. Facebook giving you whatever it thinks will keep you clicking things on Facebook, but there is probably a happy medium somewhere.)

(3) The challenging frontier may be in grant submission and reviewing, where proposers are typically not anonymous to the reviewers, which surely leads to some biases. I have heard about government programs where they did use double-anonymous reviewing and it seemed weird to me. (Probably this is a situation where track record should matter, yet trying to summarize your own track record while remaining effectively anonymous seems really hard...)

We hear this a ton from our friends at big companies, but... surely most of them use Linux? Or Git? Or x264, OpenJDK, GIMP, or VLC? Or (if you include LGPL) the WebCore portions of Chrome/Safari/Edge, which originated in KHTML/Konqueror? Or GTK, Cairo, ffmpeg, or WINE?

It's a little hard to believe the "GPL" is that much of a problem to the industry given how popular *GPL software remains in most places.

GPLv3 I realize is a different story, but even then, the companies seem to find a way to hold their nose when they want to. (When we first released Mosh as GPL 3+, we got a call from Apple, who were unhappy that their employees were using Mosh to connect to servers because Apple apparently doesn't want employees to be installing any GPL v3 software on their company-owned Macs. On the phone call, I told them that (a) I didn't think they had anything to worry about in terms of actual problems from the GPLv3, and (b) if they really disagreed, we're open to the conversation, but it would cost them a lot of money for me to want to think about what it would take to give them Mosh under a different license. Somehow they ended up concluding that the GPLv3 wasn't that bad after all...)

Hi -- original Mosh author here. We're excited to be doing a new release, with a new team of maintainers (not academics!), fuzzing from oss-fuzz, 24color support, etc., and would appreciate all the testing of the release candidate that Hacker News is able to provide. Hopefully we'll have a 1.4 soon. Details here: https://mailman.mit.edu/pipermail/mosh-devel/2022-August/001...

Re: why has it been five years, I feel like I've written this message many times on HN (https://news.ycombinator.com/item?id=28151637 , https://news.ycombinator.com/item?id=31010005), but here's another go. :-) We take Mosh's security seriously. In the ten years that Mosh has been out (https://news.ycombinator.com/item?id=3819382), we've never had a real security hole -- that we know about. That's a fantastic (apparent) track record. I don't want us to boast about it because it's just tempting fate, and of course you never really know if you have a security hole (just the ones you find or people tell you about), but, in terms of "security holes discovered," Mosh's track record compares really well with OpenSSH, OpenSSL, etc. Of course those codebases (a) have a lot more features than Mosh, and do more than Mosh, and (b) release more often than Mosh, but I'm happy (and I think the rest of the team is too) that Mosh does the thing it does well and without having made our users vulnerable. Back in 2012 when Mosh first came out, with a novel C++ codebase, and a novel secure datagram protocol, a lot of people were skeptical that it was worth trusting, and I'm pretty happy with how things turned out. This was all before HeartBleed and before QUIC, when self-assured people told me to "use something vetted, like OpenSSL" instead of our own new protocol and codebase. It took a long time to earn the community's trust, and now there's a few million people using Mosh, and I don't want us to fuck that up.

I had handed off the project to another maintainer, and my understanding is that he had some health challenges or maybe just got burnt out. Given the choice between "release the code with lots of new features, but without the normal procedure and without an active maintainer to take responsibility for it" vs. "don't release," we chose the conservative option. I think that was the right choice. Of course many people equate "how recently was there a release" to "how secure is this software," and... I guess we are a counterexample? Not sure what else to say.

Thank you to HN and Patrick Collison for publicizing Mosh back when it first came out ten years ago (https://news.ycombinator.com/item?id=3819382) and hope the next 10 years goes similarly... uneventfully and full of secure, reliable, mobile terminal sessions. :-) And thank you to all of you who get a chance to test the release candidate!

Thank you! We are about to have a new release (with a new team of maintainers) and would appreciate all the testing of the rc that Hacker News is willing to provide. Details here: https://mailman.mit.edu/pipermail/mosh-devel/2022-August/001...

Heya,

(1) Thank you for implementing this in JSC!! I hope they take it, it makes it into Safari, and the tail-call proposal advances.

(2) I don't think you are exactly right about the call stack being observable via thrown exceptions. There's no formal spec for the v3 exceptions proposal yet, but in the documents and tests, there's nothing that would change in WebAssembly core to make the call stack observable. (There's no ".stack property" that would be added to Wasm itself.) It's true that the proposal amends the JS API (but only the JS API) to describe a traceStack=true option; from Wasm's perspective I understand that's just an ordinary exception that happens to include an externref value (just like any other value) to which Wasm attaches no special significance. The Web-based engines can attach an informative stack trace if they want, but there's no requirement preventing frames from having been optimized out. The non-Web engines won't have to think about this.

(3) I think the real reason that a Wasm engine can't implicitly make tail calls proper is that the spec tests forbid it, basically because they didn't want the implementation base to fragment by having some engines perform an optimization that changes the space complexity of a program, which some programs would have started to depend on. (The spec tests say: "Implementations are required to have every call consume some abstract resource towards exhausting some abstract finite limit, such that infinitely recursive test cases reliably trap in finite time. This is because otherwise applications could come to depend on it on those implementations and be incompatible with implementations that don't do it (or don't do it under the same circumstances.)")

But the issue is much weaker than "call stack is observable" -- it's more like "infinite recursion must trap eventually, but it can be nondeterministic when."

More discussion here: https://github.com/WebAssembly/spec/issues/150

Mosh uses AES-OCB (and has since 2011), and we found this bug when we tried to switch over to the OpenSSL implementation (away from our own ocb.cc taken from the original authors) and Launchpad ran it through our CI testsuite as part of the Mosh dev PPA build for i686 Ubuntu. (It wasn't caught by GitHub Actions because it only happens on 32-bit x86.) https://github.com/mobile-shell/mosh/issues/1174 for more.

So I would say (a) OCB is widely used, at least by the ~million Mosh users on various platforms, and (b) this episode somewhat reinforces my (perhaps overweight already) paranoia about depending on other people's code or the blast radius of even well-meaning pull requests. (We really wanted to switch over to the OpenSSL implementation rather than shipping our own, in part because ours was depending on some OpenSSL AES primitives that OpenSSL recently deprecated for external users.)

Maybe one lesson here is that many people believe in the benefits of unit tests for their own code, but we're not as thorough or experienced in writing acceptance tests for our dependencies.

Mosh got lucky this time that we had pretty good tests that exercised the library enough to find this bug, and we run them as part of the package build, but it's not that farfetched to imagine that we might have users on a platform that we don't build a package for (and therefore don't run our testsuite on).

I don't think anybody's saying that employees were wronged by options backdating. It's fine for companies to award options to different employees at a uniform strike price out of a concern for fairness. In broad terms, companies can compensate their employees mostly however they like.

But whatever compensation a company awards, they have to account for it and in some cases truthfully disclose it. It matters when the employee gains the ability to exercise the option; awarding an at-the-money option isn't the same as an in-the-money option (and wasn't in those days).

Lots of companies were doing this; in Apple's case, they falsified the minutes of their Board of Directors to invent a special meeting so they could pretend they had compensated Steve Jobs (and others) differently. (https://www.theguardian.com/business/2006/dec/30/citynews.ne...)

(Speaker in that video here)

You're right that this is measuring the WebRTC.org codebase (as used in Chrome, Firefox, etc.), not necessarily the WebRTC protocol. Better URL and demo/talk videos are here: https://snr.stanford.edu/salsify

But the issue probably isn't with the bandwidth estimator or congestion-control algorithm -- you probably can't fix this by taking some WebRTC implementation and plugging in better ones. The core issues as we see them are about the architecture of the WebRTC.org codebase, and frankly all WebRTC source/sink implementations we're aware of, in particular:

(a) even with perfect bandwidth estimation, libvpx and libx264 (and, we think, typical hardware encoders) as configured are bad at achieving the requested bitrate over short timescales, meaning that "overlarge" coded frames are regularly being sent, and techniques like reference invalidation or golden/altref encoding are never (?) used to skip sending an overlarge coded frame or to retry encoding the same frame at a lower quality before sending. [At a technical level, the interface between the encoder VBV buffer model and the bandwidth estimator/CC algorithm is very inconvenient -- to have these two control loops running independently, trying to do similar things at similar timescales, isn't great.]

(b) loss recovery does not work well, and again features like reference invalidation to recover quickly do not seem to be well-used in practice (the second half of https://youtu.be/jaDelb4JnP4 makes this pretty clear),

(c) the WebRTC.org codebase is so complex, with so many modes that it can get settled in, that trying to reason about these behaviors or explore them systematically is quite challenging, and

(d) because there are several layers of buffering on the receiver-side, and because the sender-side code will change things like the camera's frame rate, it's hard to measure application-level metrics [e.g. lens-to-display and microphone-to-speaker latency] robustly in a deployment, especially across a diverse hardware or OS base. (And it's easy to get a false sense of security from the network-level WebRTC metrics that are available.)

It's probably possible to produce a WebRTC source/sink implementation that works better over challenged networks and has good monitoring of application-level latency, but it would be a big job afaik. Our work was partly funded by Google, we had a high-up Google sponsor, we gave multiple talks at Google, etc., but it was challenging even to find "the people in charge" of this cross-modular stuff to talk with them, because I think the codebase in some respects mirrors the org chart. E.g. you have video compression people worrying about the encoder (and wanting to be able to plug in libvpx, libx264, and a bunch of hardware encoders to the same interface), and networking people worrying about the bandwidth estimator and CC algorithm, and it's sort of way too late to say that the interfaces or architecture needs to be refactored or that the complexity has gotten out of control. To Google's credit, they have since driven the industry to produce standardized APIs for "functional" codecs, and functional decoder ASICs now exist (not sure about encoders yet), so there is progress being made on that front at least.

No, in the U.S., the anti-circumvention provisions only apply to works still protected by U.S. copyright. (The criminal violations are also only applicable to willful violations done for commercial advantage or private financial gain.) Generally speaking, the Copyright Clause only empowers Congress to create restrictions "for limited Times" -- even the anti-circumvention rules are probably subject to this.

Nimmer explains: "Section 1201’s limitation to works that are under U.S. copyright protection means that, to the extent a technological measure effectively controls access to public domain works, circumvention of that measure does not violate the statute. (But intermingling a small amount of current material into the collected works of Shakespeare could effectively undermine that status.) By the same token, to the extent that a work, currently protected abroad, resides in the U.S. public domain for formal or other reasons, then, as to it as well, circumvention of technological measures remains nonactionable (unless, again, some protected material were intermingled with it)." 4 Nimmer on Copyright § 12A.03 (2022)

The multi-memory proposal is your best bet for this: https://github.com/WebAssembly/multi-memory

It's supported in Wasmtime, WAVM, and WABT and wasm2c, and not much else so far (https://webassembly.org/roadmap/).

You may be thinking of http://techrights.org/2020/09/15/rmsf/ :

"So I asked Bostic himself. Originally, his reply was: 'It’s true. John Gillmore & Richard Stallman convinced me that opening up the sources was worthwhile, we wouldn’t have done that without their urging.'"

We might be victims of our own success on some of this. We've never had a major security hole in Mosh (after ten years since 1.0). We're really proud of that! But that also means we've never needed to issue a security update, which some people use as a proxy for "are people looking for security holes in this project."

After a few years without an active maintainer, as of a few months ago we now have a group working slowly but actively towards a Mosh 1.4 release. I think the main benefit people are expecting will be support for 24bit color escape sequences, but I'm also hoping we can get some fuzz targets, etc.

I think you may be thinking of this: https://www.nytimes.com/2001/02/13/science/reading-the-book-...

I believe they are both CC-licensed. See https://sicp.sourceacademy.org/

A ton of work seems to have gone into this -- they have a meta-circular evaluator in JavaScript (and it's not that much longer than the original Scheme)!