nightpool

Yes! Please do this

The story that photograph is from is about distance learning enforced by the COVID pandemic. https://navajotimes.com/edu/hill-becomes-makeshift-classroom.... The family does not have internet access, and while they were issued a laptop and mobile hotspot, it only gets signal from the top of that hill.

OP may have misunderstood the context but I think it's a stretch to say they were intentionally fooled.

The post in question had early empirical data comparing bug reports from Node, Bun and Deno. It wasn't the main focus of the article, and I would love to see a deeper dive, but it showed that Bun had almost 8x the amount of "crash" or "segfault" bug reports on Github as Deno, despite having almost the same amount of total issues created. (4% of bug reports for Deno are crashes, 26% of bug reports for Bun are crashes).

This matches my experience with the runtimes in question—I tried Bun out for a very small project and ran into 3 distinct crashes, often in very simple parts of the code like command line processing. Obviously not every crash / null-pointer dereference is a memory safety issue, but I think most people would agree that Zig does not seem to make bug-free software easier to write.

There was an article about Zig on the front page just a few hours ago that attracted many "Why do I need memory safety?" comments. The fact that new languages like Zig aren't taking memory safety as a foundational design goal should be evidence enough that many people are still skeptical about its value

I can see where you're coming from, but I do think there's a fair amount of meat here. I've never used Zig, but I initially thought of it as pretty similar to other modern languages like Go and Rust, and I liked their allocator approach, but the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. I used Bun for a small data-collection project, and I liked its performance, but I ran into a lot of issues with it segfaulting (even when just passing a command line argument that was added in the most recent version!). I think that does a good job of motivating OP's argument and how Zig's language semantics directly contribute to these issues.

On the Rails side, Gitlab has an extensive set of helpers for this that a lot of Rails projects have adopted—I would love to see them pulled out into a Gem or adopted into Rails core proper: https://gitlab.com/gitlab-org/gitlab-foss/blob/master/lib/gi...

What good does having integration tests and linters do when triaging issues? When trying to figure out if a bug report is hallucinated or not?

GP linked an example of a similar project that allowed you to modify the terrain without any JS at all

I think you left this comment on the wrong article ;)

Data packs were released in October 2017! And we had command blocks in 2012 for custom maps

That's definitely true, and I think that's a testament to Minecraft / Java's strong OO design—it dovetails very nicely with the Open/Close principle. However my view is that for a mod to be a mod, there's always going to be stuff that you can't/shouldn't implement just with datapacks—whether that's complex rendering features, new entity logic, or whatever. The Mixin processor makes it really easy to build these kinds of features in a very compatible way

Not only working around proguard, but Minecraft mods are built on top of an incredibly cool and flexible runtime class file rewriting framework that means that each JAR can use simple declarative annotations like @Inject to rewrite minecraft methods on the fly when their mod is loaded or unloaded. This massively revolutionized mod development, which was previously reliant on tens of thousands of lines of manually compiled patches that would create "modding APIs" for developers to use. Putting the patching tools in the hands of the mod developers has really opened up so many more doors.

Minecraft also has a plugin system based around JSON file datapacks, but it's a lot more limited. It's more at the level of scope of adding a few cool features to custom maps then completely modding the game.

?????

I like the bit where he tried to get paid by Hackerone for the bug you reported:

     i think there a bug here on your last comment. can i report it to hackerone ? they will reward me ?

Scroll down—the discussion continues beyond the initial post

Correct, but OP was talking about access being conditional on using a proprietary browser. Users can use normal, non-proprietary browsers to access discord.com. Nothing in Discord requires users to use their proprietary browser, like this Perplexity subscription does.

Maybe because the lack of nuance in "no LLM content at all" is easier for LLMs to understand :P

EDIT: Looks like the quote you had was for an earlier version of the policy, which was changed because people did not/could not abide by it: https://news.ycombinator.com/item?id=45669846

Discord still works fine in your normal browser. I'm not aware of any content that requires the use of its Electron app—obviously it has more platform integration features, like slightly better screen sharing (and audio sharing on mac), but nothing groundbreaking.

I think the structure of this article definitely made it harder to find the details to some of these questions—the fact that it's posted as 5-8 different "blog" entries instead of a single webpage made it harder then it needed to be to get to the technical conclusions section. Also, some of the method call listings on this page: https://www.benedelman.org/applovin-execution-path/ were unnecessarily verbose, and duplicative with the later pages that actually explained the flow in more detail e.g. https://www.benedelman.org/applovin-execution-sdk/

Having all of the sections of the article on the same page would have helped surface and resolve a lot of these potential editorial issues.

How is it unsettled? If they got a warrant for it, what would prevent them from using it as evidence?

This would make sense if there weren't so many features—like Blocks, DMs, followers-only posts, etc—that were reliant on the AppView enforcing a single global view of the world. I agree that I do think the AT model does have good properties but right now too much of it is reliant on this single shared global app view

But thanks for the link to Konbini! That looks really exciting and promising and I would love to start using it if I can run it completely decoupled from Bluesky infrastructure.

> It’s much closer spiritually to RSS and plain old web

What do you mean by this? ATProto requires a giant indexing database that has access to every post in the network. Mastodon is more like a feed reader—you only get notified about the posts you care about. How is needing a giant database that knows about every RSS feed in the world closer to the plain old web?

That's interesting—my understanding is that Github Enterprise Cloud is part of the same infrastructure as Github.com, so this status page seems maybe incorrect? Probably some missing step in the runbook to update both of these pages at the same time.

I haven't worked with Fedify before, but what I'm talking about is the difference between a service that has a "translation layer" between their own internal data model and ActivityPub, and a server that actually stores full ActivityPub object's in the user's inbox and outbox, and displays them unchanged to clients. 90% of deployed ActivityPub applications—like yours!—are the former, not the latter.

A true "ActivityPub server" is almost as simple as a Bluesky PDS—all it's responsible for is 1) storing blobs of data, 2) fanning out subscriptions and 3) collecting incoming data for you to view. In the original way ActivityPub was designed, all of the actual data presentation layers—Mastodon, PeerTube, Pixelfed—were designed to be specialized clients that could communicate with the user's generic server. However, the first popular implementations cut out the client-to-server part of the protocol, so now we're stuck in a place where everyone thinks ActivityPub means you need a separate identity for every client application.

So, what I would recommend for your own username/password site is implementing an ActivityPub client, and recommending that users use it to connect to a third-party ActivityPub server. That way, the user owns the data, and they simply use your service to get access to (filtered version of) it.

Unfortunately, since this is a less implemented part of the protocol, the client APIs necessary to make this a reality haven't seen much development. And you're facing an uphill battle for user adoption. In practice, users don't seem to mind having separate accounts and identities for different clients. It reminds me a bit of the "key management problem" in e2e cryptography. Having a stable cryptographic identity is doable if you're technically minded, but most people just muddle along and don't really care about it that much—they create new keys every time they get a new laptop instead of trying to figure out cross-signing, and everything works itself out more or less fine.

Correct. All information in the system is part of a public, append-only ledger. That's the thing I'm pointing out is a fundamental weakness of the system.

Every one of these "How AT proto works" explainers focuses on data ownership—which is where ATProto shines—and glosses over data processing, where ATProto is decidedly weaker than ActivityPub. ATProto is built on a global, public view of the world, where all events are visible to a trusted global "AppServer" that can make all of the decisions for you—how to create your feed, who can see who's posts, etc—all of those decisions have to be made by a trusted intermediary. ActivityPub is more like RSS or email—your local server only has to manage the feeds you subscribe to, and your inbox is directly built from all of the posts you have access to. People you subscribe to send you your posts, and you don't have to process them at all.

This is why Bluesky could never have "private likes" in the same way Twitter or ActivityPub does—every AppView needs to track the like counts of every post in the network manually. It's a huge hassle! I just don't see this architecture winning out in the long term, when compared to the AP feed-subscription architecture.

    primarily because multiple programs can access the same identity

Actually, this was how AP was originally designed as well—it was just that the most popular early implementations took shortcuts to remove that functionality to fit them into their existing architecture. This is a direct consequence of the fact that the biggest AP implementations when it was initially adopted were descendants of older OStatus social networks, and not built to be "ActivityPub-native" from the ground up.

It's about 49 characters, which is maybe a little small but much closer to the size I normally read my ebooks at then most website these days. Most recommendations I see online for digital prose line length recommend around 55 characters at the lowest, so I think it's doing okay.

> Recently investments in homebrew almost turned it to be a paid tool.

Can you say more about this? I haven't heard about this before.

I'm not saying that they're just "a nice community member", I'm saying that they're the ones doing the work. They're not randos, they're trusted maintainers in the ecosystem with a proven track record. After the purge, rubygems and Bundler has only one active maintainer, one who's splitting his time between Rails, Ruby core, and many other open source projects. The bundler and gem-specific experts have been removed, and we've gone from a bus factor of 4-5 to a bus factor of 1. This is much, much more unacceptable then the theoretical risk of a trusted, active maintainer with 10+ years of community experience suddenly deciding to go rogue and rewrite history (has this ever happened in the history of a supply chain attack?)

Also, commit access to Github doesn't even say anything about access to deploying the actual package on rubygems. If security really was the goal, there were a million less invasive ways to make this change then revoking commit access from the active maintainers. Set up branch protections, require approvals, etc. There are a lot more tools in the toolbox other than "remove all of the maintainers".

"These randos" are our friends and fellow contributors. Probably everybody in the Ruby community has worked with theme in one capacity or another. The article provides no reason why they should have had their contribution permissions revoked. Just because you think of Ruby as a "niche DSL" and the people maintaining its core infrastructure as "randos" doesn't mean the rest of us do.