If you have a project template or a tool that otherwise sets up a project but leaves it in the user's hands to create a git repo for it or commit the project into an existing repo, then it would be better for it to create a self-excepting .gitignore file than to have to instruct the user on special git commands to use later.
There are plenty of cases where the operator of archive.today refused to take down archives of pages with people's identifying information, so it's a huge double standard for them to insist on others to not look into their identity using public information.
Bluesky is architected so you can export your data and follows and followers to your own or someone else's infrastructure at any time. There are some groups that have taken that offer and moved off of Bluesky's infrastructure (see Blacksky). The fact that most people aren't doing that is a sign that people are happy with how Bluesky-the-company is running things. What's the issue?
And Bluesky is better because you're not locked in and can export your posts, follows, and followers off of their infrastructure if they start being evil or you randomly feel like it. Companies like Twitter effectively wield network effects to stop people from leaving. All of one's activity on Twitter increases the sunk cost to keep them on Twitter in a way that's not true for Bluesky.
I recognize that Bluesky is at present more open than Twitter and that all of the necessary building blocks for the infra are publicly available. That's good of course.
However I think the view you expressed there is misguided. If Bluesky locked out third party infra tomorrow presumably the vast majority of people would not move. Thus vendor lockin via network effects remains. (Ie you are always free to leave but you'd be moving from a metropolis to a backwater.)
The only scenario where this isn't true is one where no more than a few percent of the people you interact with reside on any given node. By that metric small AP nodes pass while large ones such as the flagship Mastodon node fail. Similarly Gmail and Outlook fail while any self hosted mail server passes.
I don't think anyone one knows yet, nor does that answer need to be answered soon, or perhaps ever, bluesky can die and atproto can go on. They are not existentially tied together
> [..] machine-readable archive of information associated with your account in HTML and JSON files. [..] including your profile information, your posts, your Direct Messages, your Moments, your media ([..]), a list of your followers, a list of accounts that you are following, your address book, Lists that you’ve created, are a member of or follow, [..], and more.
(Note that I actually elided some additional things that are included in the export, for readability's sake.)
You can't actually use your followers and following list from X on other sites. With Bluesky, you can move your profile onto other infrastructure, continue to see posts from people you follow, and make new posts that your followers still see like nothing happened. It's like how if you own your own domain name, you can set your MX records to whatever email service you want and change it when you want without affecting anyone you're having email conversations with.
Ah, I see. Your use of the term "export" made me misunderstand. Though now that I've thought about it for a few minutes, I'm not sure what verb makes sense [to me] there. I guess "migrate?"
whether you agree or not, asking "what's the issue" misses the point very badly, since the article is almost entirely about what the issue is (i.e. that most people will not change defaults and the default is to centralise on the bluesky servers)
The fact that the system is built around this escape hatch makes it miles better than almost all other social networks. An escape hatch doesn't need to be used by most people to be valuable.
I know when I’m using a Nostr app because its logo is an endless spinner.
At the scales these systems run at, you need large indexes. Distributing those indexes across many nodes would require a breakthrough in federated queries, and if you have one of those lying around I’d pay good money for it.
Indeed, and as a consequence Nostr has a dogshit user experience and approximately noone on it. Boy I sure love reading nothing and talking to nobody except nerds that jerk themselves off about how decentralized their platform is.
yeah I'm not saying the blog is right or wrong; I'm just saying that describing bsky's features and asking "what's the issue?" means you aren't engaging with what it's actually saying.
Saying you do does not change what others see across your comments. I'd suggest reading the HN guidelines again. I do myself from time to time because there is some good internet decorum wisdoms in there. I hope by reading them, you can see your comments more like how we see them.
In most situations, auto-generating the equivalent of .h files for a library based on export statements in the source code would be fine and a useful simplification.
LLMs are amazing and I do seriously wonder if the singularity could happen in my lifetime ... but there definitely are people over-hyping present capabilities too much right now. If present models were fully human-level proper-extended-Turing-test-passing AGI, then the results on the economy and the software ecosystem would be as immediately obvious and world-changing as a comet impact.
I don't think Rakyll or Andrej are claiming these things; I think they're assuming their readers share more context with them and that it's not necessary to re-tread that every time they post about their surprise at AI currently being better than they expected. I've had the experience multiple times now of reading posts from people like them, nodding along, and then reading breathless quote-tweets of those very same posts exclaiming about how it means that AGI is here right now.
The explanation it gives at the start appears to be on the right track but then the post has two separate incomplete/flawed attempts at coding it. (The first one doesn't actually put the expected crypt() output in the payload, and the second one puts null bytes in the password section of the payload where they can't go.)
Automatically running LLM-written code (where the LLM might be naively picking a malicious library to use, is poisoned by malicious context from the internet, or wrongly thinks it should reconfigure the host system it's executing code on) is an increasingly popular use-case where sandboxing is important.
That scenario is harder to distinguish from the adversarial case that public hosts like Cloudflare serve. I don't think it's unreasonable to say that a project like OpenWorkers can be useful without meeting the needs of that particular use-case.
Something like "all code is run with no permissions to the filesystem or external IO by default, you have to do this to add fine-grained permissions for IO, the code is run within an unprivileged process that's sandboxed using standard APIs to defend in depth against possible v8 vulnerabilities, here's how this system protects against obvious possible attacks..." would be pretty good. Obviously it's not proof it's all implemented perfectly, but it would be a quick sign that the project is miles ahead of a naive implementation, and it would give someone interested some good pointers on what parts to start reviewing.
This is exactly where we see things heading. The trust model is shifting - code isn't written by humans you trust anymore, it's generated by models that can be poisoned, confused, or just pick the wrong library.
We're thinking about OpenWorkers less as "self-hosted Cloudflare Workers" and more as a containment layer for code you don't fully control. V8 isolates, CPU/memory limits, no filesystem access, network via controlled bindings only.
We're also exploring execution recording - capture all I/O so you can replay and audit exactly what the code did.
Production bug -> replay -> AI fix -> verified -> deployed.
This is assuming that the process could have done anything sensible while it had the malformed feature file. It might be in this case that this was one configuration file of several and maybe the program could have been built to run with some defaults when it finds this specific configuration invalid, but in the general case, if a program expects a configuration file and can't do anything without it, panicking is a normal thing to do. There's no graceful handling (beyond a nice error message) a program like Nginx could do on a syntax error in its config.
The real issue is further up the chain where the malformed feature file got created and deployed without better checks.
I do not think that if the bot detection model inside your big web proxy has a configuration error it should panic and kill the entire proxy and take 20% of the internet with it. This is a system that should fail gracefully and it didn't.
> The real issue
Are there single "real issues" with systems this large? There are issues being created constantly (say, unwraps where there shouldn't be, assumptions about the consumers of the database schema) that only become apparent when they line up.
I don't know too much about how the feature file distribution works but in the event of failure to read a new file, wouldn't logging the failure and sticking with the previous version of the file be preferable?
That's exactly the point (ie just prior to distribution) where a simple sanity check should have been run and the config replacement/update pipeline stopped on failure. When they introduced the 200 entry limit memory optimised feature loader it should have been a no-brainer to insert that sanity check in the config production pipeline.
Or even truncating the features to their limit and alerting through logs that there is likely performance degradation in their Bot Management.
I'm really confused how so many people are finding it acceptable to bring down your entire reverse-proxy because the length of feature sets for the ML model in one of your components was longer than expected.
One feature failing like this should probably log the error and fail closed. It shouldn't take down everything else in your big proxy that sits in front of your entire business.
Yea, Rust is safe but it’s not magic. However Nginx doesn’t panic on malformed config. It exits with hopefully a helpful error code and message. The question is then could the cloudflare code have exited cleanly in a way that made recovery easier instead of just straight panicking.
Would expect with a message meet that criteria of exiting with a more helpful error message? From the postmortem it seems to me like they just didn’t know it even was panicing
> However Nginx doesn’t panic on malformed config. It exits with hopefully a helpful error code and message.
The thing I dislike most about Nginx is that if you are using it as a reverse proxy for like 20 containers and one of them is up, the whole web server will refuse to start up:
nginx: [emerg] host not found in upstream "my-app"
Obviously making 19 sites also unavailable just because one of them is caught in a crash loop isn't ideal. There is a workaround involving specifying variables, like so (non-Kubernetes example, regular Nginx web server running in a container, talking to other containers over an internal network, like Docker Compose or Docker Swarm):
location / {
resolver 127.0.0.11 valid=30s; # Docker DNS
set $proxy_server my-app;
proxy_pass http://$proxy_server:8080/;
proxy_redirect default;
}
Sadly, if you try to use that approach, then you just get:
nginx: [emerg] "proxy_redirect default" cannot be used with "proxy_pass" directive with variables
Sadly, switching the redirect configuration away from the default makes some apps go into a redirect loop and fail to load: mostly legacy ones, where Firefox shows something along the lines of "The page isn't redirecting properly". It sucks especially badly if you can't change the software that you just need to run and suddenly your whole Nginx setup is brittle. Apache2 and Caddy don't have such an issue.
That's to say that all software out there has some really annoying failure modes, even is Nginx is pretty cool otherwise.
reply