LukeShu

One trick is to look at whatever camera FRC (high school robotics competition) is using in their kits, since those are requirements for putting the camera on a robot, and they've got to put out a new kit each year, so there will always be a current model.

Last I knew, they were using Axis cameras, but that was a few years ago.

It might not have the answers he's looking for. When I've gone on such hunts, yeah, any one cost isn't so bad, but if I open that box of paying for documents, I could easily drop thousands of dollars and not actually be any closer to the answer.

> “No bullshit” is no more. https://www.gandi.net/en/no-bullshit

They mostly phased-out the "no bullshit" slogan from all of their branding with the v5 migration in 2018. It went from being in the homepage's <title> and the first thing you see on the homepage[1] and in the header at the top of every page to being just a tiny link under "About Us" in the homepage's footer[2].

I get phasing it out, to be more "business friendly" or whatever; but doing it at the same time as the big v5 UI and accounts overhaul... it seemed to me to be an admission that the fancy new Javascript UI was bullshit.

[1]: https://web.archive.org/web/20180104001527/https://www.gandi...

[2]: https://web.archive.org/web/20181230012842/https://www.gandi...

There's an in-game credits screen.

You know what I love? Finding threads like this in

> OP: Posts a question

> Anon: [deleted by shreddit/PowerDeleteSuite/whatever]

> OP: Thanks, that solved my issue!

It's a modern version of https://xkcd.com/979/ !

Specifically, this: https://www.amazon.com/gp/product/B09HTWH46C/ It's much easier than trying to hold a mirror with one hand so I can see what I'm doing with the other hand.

Already happening. My soldering iron, pimple-popper camera, and toy lightsaber all take USB-C. Though the lightsaber isn't compliant and just wired up the power and ground pins from the USB connector with no more complexity than barrel jack, rather than doing the proper USB-C/PD things to indicate how much power it can take, so some cables/chargers won't even give it anything.

To be clear, me staying/leaving when I did had nothing to do with the vesting schedule.

In 2018 I was hired as full-timer number 13 from an HN thread. I stayed there for 4 years.

The company was 90-some people when I left. We posted in the HN threads every month, but as far as I know, I was the only one hired from HN. One time I asked someone from HR about it, and they told me that we only got a very small number of responses from the HN threads, but that they were generally high-quality candidates, and that it just never worked out. In at least one of the cases we tried to hire the person, but he ended up ghosting us (I remember that one because I interviewed him... and now often notice his username in the comments).

I've almost never seen a recipe book that didn't have at least one recipe where some aspect of the picture didn't blatantly contradict the recipe; i.e. it was just a stock photo.

Plan 9 definitely wasn't built with the thought that the endgame was ever more powerful desktops doing most things locally. "Connected over a network to send and receive files" is only technically true, yeah it's all around the 9P protocol which is a filesystem protocol, but it's a world where everything is a file. A window on your screen is a file. A CPU is a file. And app is a directory with files in it. The Plan 9 vision is all the things you describe, but more seamless. Firing up a a surreally large cloud machine isn't starting a VM with its own separate OS and configuration, it's connecting to a cloud CPU and your tasks transparently running on it. Mostl applications running on a cluster of machines that expose an HTTP interface to your browser are instead applications running on a cluster of machines that expose a 9P interface to your OS. Your impression of "the endgame was having ever more powerful desktops who did most things locally" was the Unix trajectory, and steering away from that was the big departure of Plan 9 from Unix.

I was responding to your assertion that people get mad because YouTube takes a cut. The alternative (Patreon) also takes a cut.

I spend more supporting YT creators than what YouTube Premium costs.

I'm fine paying for things when I say "I like this, I want more of it." YouTube itself is the worst part of the experience, it's the part I want less of. YT would have to have way fewer dark patterns and bad behaviors for me to even consider paying for YouTube Premium.

So? Patreon's taking a cut (but YouTube takes a bigger cut; a quick search indicates 30% vs 8%-12%). I'm fine with YouTube memberships in principle; if a creator that I support said "consider switching your support from Patreon to YouTube", I would. But there's no way I'm signing up for YouTube Premium.

Note that that's the same redirect it had been doing for a long time (except for a bit earlier today).

I'm not sure what happened, since the relevant file hasn't been committed to in a while: https://web.cvs.savannah.gnu.org/viewvc/www/www/licenses/.sy...

That's been the URL for a long time. It's that until a day or so ago, https://www.gnu.org/licenses/gpl.html did a 302 redirect to http://www.gnu.org/licenses/gpl-3.0.html .

It's a copyleft license; and lots of folks on HN seem to think that copyleft, while being open, isn't business friendly.

Perhaps you could script auto-delimiters. But it has no ability to format the text; you couldn't add syntax highlighting with scripting.

Keyboard with some mouse sprinkled in, sure. But Acme is very mouse heavy.

I think the chain of influence flows from ex/vi to sam, not the other way around?

It's to prevent CSRF attacks. The attacker writes their own client and does half of a login on their own end (getting an authorization-code, but not yet exchanging it for an access-token), and then tricks the end-user to navigate to //service/connect-slack-finalize?code=<attackers-code>&state=<whatever>. But with the state parameter, the client can check the state parameter against a session cookie that it set previously, and say "wait a minute, this is the conclusion of a login from a different browser". Depending on what all session-state the client is keeping track of, it may make sense to sign that state-parameter-nonce to avoid having to remember session state server-side; but the simple case would be to just check whether it == a cookie value.

.well-known/openid-configuration is specified as part of OpenID Connect (OIDC) Discovery[1]. OIDC is separate from and on-top-of OAuth2. The OIDC specs come through the OpenID Foundation, not through the IETF (so not RFCs). (Also, while what they specify is super useful, they aren't nearly as well written as RFCs tend to be :) )

[1]: https://openid.net/specs/openid-connect-discovery-1_0.html

> that's not correct in the most common flow?

No, he's right, I was misremembering (assuming "the most common" flow is the "authorization code" flow specified in RFC 6749 §4.1). The user-agent provides a one-time "authorization code" to the client via a GET, and then the client receives that "authorization code" and does its own POST to the IDP to exchange that "authorization code" for the final "access token".

My apologies, it's been a while and I was forgetting about the authorization-code exchange step. So yes, for the most part "client"s can treat the bearer token as opaque. But "resource server"s absolutely cannot.

> If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint.

If it's a JWT, which it doesn't have to be. OIDC allows the token to either be an RFC 6750 opaque token, or an RFC 7523 JWT, and overwhelmingly implementations use a "bearer" (6750) token. But, most of the time it's a JWT, so as I said, closing your eyes and pretending it's a 7523 token works, and so then you can just pull the keys from the JWKS endpoint.

> Introspection is standardized and an RFC.

In my experience, it is exceedingly rare for an IDP to implement RFC 7662 token introspection

> All these URLs are defined and provided via the .well-known/openid-configuration endpoint.

Yeah, OIDC-discovery is pretty sweet. And if the IDP implements OIDC-discovery, then it probably implements OIDC-core, or at least enough of it that you can use the user-info endpoint, like I mentioned. But I've seen IDPs that don't.

Have you ever used OAuth2 outside of OIDC?

My apologies about "to know if your post-redirect-uri is getting spoofed" and then my example exploit; I was misremembering and forgetting the authorization-code step.

If you're only implementing a "client", then yeah, you can probably get away with never caring about inspecting the token. But if you're implementing a "resource server", then you'll need to, and it's all implementation-defined (but overwhelmingly that implementation is "it's a JWT").

If it's encryoted E2E, then you don't need to inspect the server side to verify that. And the client is FOSS, anyone can inspect it. (It is my understanding that group chats are not encrypted; I have not cared to verify that one way or the other, but I could.)

> In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction?

If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon signature verification. It could be anything.

> At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site.

So you redirect the user's browser to the IDP, with the nonce in the URL. The user grabs that nonce from the URL bar, then manually navigates to your redirection-endpoint, putting that nonce and their own fabricated token in the URL.

> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol

> OAuth supports lots of different scenarios.

But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecified by OAuth. How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed):

- OAuth: implementation defined

- most implementations: use our library, which validates the token using undocumented logic

- OIDC: there's a user-info endpoint you can call to, but lots of OAuth authorization servers don't fully implement OIDC, and even if they do, that's a lot of extra round trips

- RFC7523: The token is a JWT, validate the signature and claims... but everyone issues RFC6750 "bearer" tokens, not RFC7523 "urn:ietf:params:oauth:grant-type:jwt-bearer" tokens. But if you just close your eyes and pretend that your 6750 opaque token is actually a 7523 JWT and parse+validate it as such, that'll work most of the time.

So yeah, OAuth is hard because there's no great generic library, because a core part of it is implementation-defined, so you have to either do it yourself or use a specific implementation's library, and none of those libraries work quite the same.

(In the above, and for 99% of folks, "OAuth" = RFC6749+RFC6750)

"That thing was a disaster, so let's do the opposite of it" isn't more brain-dead than "let's superficially copy the familiar/trendy thing". (I say "superficially" with regard to TOPS-10→CP/M→DOS and Xerox→Windows copying; the VMS→NT copying is a much more in-depth influence and hiring of talent.)

I wouldn't say that the FSF's criteria are unprincipled. At his pre-Libreplanet talk on 2023-03-17, RMS gave a principled and pragmatic explanation of the criteria. I don't agree with him on his application of some of the principles or on where the appropriate places to make compromises between principles and pragmatism are; but that doesn't mean his conclusions are unprincipled.

Yeah. That said, I've become disillusioned with FUSE over the course of writing this. FUSE is... not great, it's just what we're stuck with. Suggestions as to alternatives to FUSE would be welcome.