88 karma · joined October 9, 2022
Like I mentioned I don't work on Muse, and I suppose it'd wouldn't be appropriate for me (self-identified Meta employee) to publicly speculate on what defenses do and don't exist or what is intended. (sorry kinda a cop-out, I know).
Thanks for providing specific links to the specific concerns being raised.
TBH I saw none of those comments by scrolling forward or backwards from the original link. Now it turns out I supposed to be checking quote tweets, not just scrolling like you said above? (tbf I'm not familiar with the neuromatch UI, could be user error on my part).
Again, I think this would've gone smoother if you actually articulated the problem you're concerned about, instead of linking to a "personal notepad" which you acknowledge has mistakes and isn't easily intelligible, and then blaming me for missing the actual point.
I'll look through these new comments later.
Edit: I see from your original comment what you meant by "top-level". I originally assumed you just meant top of the thread. I'll take the L here.
a) More being surprised the muse will just provide internal details (which again, as intended) b) the bash scripts are ugly (okay? I don't think that's what we're arguing about) c) surprise that muse runs as root (then realizing this is explained by the VM-in-VM model and linking to the blog which explains this) d) surprise that muse can run as a seed box (idk is this supposed to be the security concern?)
Could you please be more specific about which part you're concerned about? I think that'd be more productive than linking to a long thread, me responding to what I see, then being told that it's just a scratch pad and I'm silly for taking it seriously but also if I look closer I'll see the deeper truth.
I think you're saying that prior actions justify the beliefs you hold. Fair enough, I'll concede that for the sake of argument.
My above comment still stands. Even if your beliefs are justified, that doesn't mean you should treat non-evidence as evidence supporting your beliefs. (Tbh my point is kinda trivial/pedantic. But I feel like folks just always want to double down that every criticism of meta is correct).
You're free to believe whatever you want about Meta. But no, you shouldn't point to non-evidence, interpret it through the lens of your prior beliefs, and then claim that it's actually evidence supporting your beliefs.
> Aside, if “a skill file organizing purchase history in markdown format” is the only thing you took away from that thread, you might want to take a closer look.
That's what that specific quote I was referencing was referring to. I already responded to the supposed prompt injection/security concerns above.
But if someone posts the thread with no other context than "check this out", then it seems appropriate explain this missing context.
And for the record, I did scroll back read through what he's saying as you suggested. The broader context is exactly what makes it clear he's just a bit confused about what he's "uncovered". (Obvious caveat: I haven't read through everything this guy has written, I could be missing something)
We all know Meta can already track things like certain purchases. A skill file telling AI how to format purchase history in markdown format is not going to help any of Meta's ads or RecSys systems.
You can believe Meta does bad things without thinking everything Meta does is an example of said bad things
You're free to speculate that Meta is lying about what it will or won't use the data for. I won't argue over that. That's an important topic and I'm not gonna persuade anyone via an HN comment. Skepticism is fine
But the example linked to in the above comment is not evidence of that at all. A skill explaining how to format purchase history in markdown format is not evidence of hidden motivations.
In general the entire thread is nothing-burger, and that's all I'm getting at.
And idk what's even being implied by that quote. (Yes, it tries to help you shop. And? Or is the critique just that OP doesn't like the prose in that markdown file?)
Disclaimer: I work at Meta, not on Muse
My point is that "can be seen from space" is an awful way to communicate that. It provides no useful intuition for the scale of "10 inches per year".
We have very good satellites! Lots of things can be seen from space. "can be seen from space" is an awful way to provide readers intuition for the scale of something.
Discovering good locations for data centers is genuinely a difficult problem. They're relatively scarce. Bidding wars seem completely plausible.
The described pattern is standard in Meta. This, along with the infrastructure and tooling to support it, was the single largest "devx quality of life improvement" in my experience moving to big tech.
TL;DR: assuming you've squashed all regular non-determinism (itself a tall ask), you either need to ensure you always batch requests deterministically, or ensure all kernels are "batch invariant" (which is absolutely not common practice to do).
It says docker compose is at the "wrong-level of abstraction", but I kept feeling the author was instead expecting docker compose to solve different problems that it was ever meant to solve.
In fact, they seem to be expecting a highly-opinionated, high-level interface which solves problems that I don't think anyone using docker compose in prod should even be worried about.
A lot of concerns seem to be around avoiding spinning up duplicate instances of reverse proxies, databases, and caches. First of all, why is this a concern? Idle threads have basically no impact on a system, so this generally isn't a concern. This is a nuanced and context-dependent issue, but generally it won't even make the list of top-100 performance bottlenecks for most applications. Yet the article takes for granted that the benefits of solving this problem outweigh the many cons of coupling them together.
Even if you wanted to enforce your applications sharing a postgres instance under the hood, why would you want that to be black-magic performed by the container orchestrator?
Other stuff like DB backups just don't seem like issues docker compose users have. If you need to orchestrate across multiple nodes in order to meet your SLOs, then don't use docker compose.
Finally, it seems like the actual solution is significantly under-discussed. I both have tons of questions about how it's supposed to work, and I see lots of shortcomings with the parts that I do understand.
Beyond the specific issues I see, the fundamental attitude seems to be "force everyone to architect their applications in a very specific way, and don't even try to support any use cases which fall outside of it". You need a damn good reason to be that opinionated about these sorts of things, and it by definition will only work well in specific contexts. I'd be interested to read an article which tried to articulate why such an opinionated API would improve SDLC-considerations over docker-compose, but I don't think that's the article I just read.
Not only is it a stretch to wonder about parallels between a basic Calc II concept and Quantum Field Theory, but is seems like the exponential function is the exact opposite of the example you provided.