halter73

Not that I defend all of Valve’s business practices, but last I heard, you’re only prevented from sell games cheaper on other platforms if the thing you’re selling is Steam keys.

AFAIK, this restriction doesn’t apply if you’re distributing via a different market place.

If that’s true, that seems fair since you’re relying on Valve’s infrastructure to support the sale.

> 6. People who realize the game theory optimal strategy is to announce you're pressing blue and convince everyone else to press blue, but privately press red.

A lot of this analysis depends on accurately guessing how people will react, so it's probably hard to say any strategy is game theory optimal without a lot of unrealistic simplifying assumptions.

In a world where you're able to convince a lot of people anything, it might better to convince everyone to press red. If it looks like 99.99% of people will press red without your influence, you're probably best off spending your time convincing the .01% who might press blue not to do so.

It also has the upside of not making you a dirty liar. I wonder, what would Kant think about this hypothetical?

I think this conflates two different eras/layers. NT 4 famously moved the window manager/GDI/graphics subsystem into kernel mode, so that’s probably the “opposite direction” history. But modern GPU-driver recovery is WDDM/TDR, and it very much still exists: WDDM splits the display driver into user-mode and kernel-mode components, and TDR resets/recovers a hung GPU/driver instead of requiring a reboot.

https://learn.microsoft.com/en-us/windows-hardware/drivers/d... https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

I also update NVIDIA drivers regularly on Windows 11 without rebooting, though that’s install-time driver reload rather than exactly the same thing as TDR.

No, but they chose to include it. Presumably there were a lot less apt references they chose not to include.

There's a link at the top of the README to https://0x00eb.itch.io/tux-racer where you can play it without needing to host it yourself.

I'm not sure this is old enough, but could you be referencing https://neal.fun/infinite-craft/ from https://news.ycombinator.com/item?id=39205020?

> Each request will hit a new random worker, but your response is supposed to go on some other long-running SSE stream.

It seems your knowledge is a little out of date. The big difference between the older SSE transport and the new "Streamable HTTP" transport is that the JSON-RPC response is supposed to be in the HTTP response body for the POST request containing the JSON-RPC request, not "some other long-running SSE stream". The response to the POST can be a text/event-stream if you want to send things like progress notifications before the final JSON-RPC response, or it can be a plain application/json response with a single JSON-RPC response message.

If you search the web for "MCP Streamable HTTP Lambda", you'll find plenty of working examples. I'm a little sympathetic to the argument that MCP is currently underspecified in some ways. For example, the spec doesn't currently mandate that the server MUST include the JSON-RPC response directly in the HTTP response body to the initiating POST request. Instead, it's something the spec says the server SHOULD do.

Currently, for my client-side Streamable implementation in the MCP C# SDK, we consider it an error if the response body ends without a JSON-RPC response we're expecting, and we haven't gotten complaints yet, but it's still very early. For now, it seems better to raise what's likely to be an error rather than wait for a timeout. However, we might change the behavior if and when we add resumability/redelivery support.

I think a lot of people in the comments are complaining about the Streamable HTTP transport without reading it [1]. I'm not saying it's perfect. It's still undergoing active development. Just on the Streamable HTTP front, we've removed batching support [2], because it added a fair amount of additional complexity without much additional value, and I'm sure we'll make plenty more changes. As someone who's implemented a production HTTP/1, HTTP/2 and HTTP/3 server that implements [3], and also helped implement automatic OpenAPI Document generation [4], no protocol is perfect. The HTTP spec misspells "referrer" and it has a race condition when a client tries to send a request over an idle "keep-alive" connection at the same time the server tries to close it. The HTTP/2 spec lets the client just open and RST streams without the server having any way to apply backpressure on new requests. I don't have big complaints about HTTP/3 yet (and I'm sure part of that is a lot of the complexity in HTTP/2 was properly handled by the transport layer which for Kestrel means msquic), but give it more time and usage and I'm sure I'll have some. That's okay though, real artists ship.

1: https://modelcontextprotocol.io/specification/2025-03-26/bas...

2: https://github.com/modelcontextprotocol/modelcontextprotocol...

3: https://learn.microsoft.com/aspnet/core/fundamentals/servers...

4: https://learn.microsoft.com/aspnet/core/fundamentals/openapi...

That github issue is closed because it's been mostly completed. As of https://github.com/modelcontextprotocol/modelcontextprotocol..., the latest draft specification does not require the resource server to act as or poxy to the IdP. It just hasn't made its way to a ratified spec yet, but SDKs are already implementing the draft.

It really depends on if you're dealing with an async stream or a single async result as the input to the next function. If a is an access token needed to access resource b, you cannot access a and b at the same time. You have to serialize your operations.

It probably depends on your lists. My uBlock Origin config had a global CSS rule blocking any elements with a #mc_embed_signup id.

Can you provide a citation for this? I’ve read older RFCs that "recommend" recipients allow single LFs to terminate headers for robustness. I’ve also read newer RFCs that weaken that recommendation and merely say the recipient "MAY" allow single LFs. I’ve never noticed an HTTP RFC say you can send headers without the full CRLF sequence, but maybe I missed something.

https://datatracker.ietf.org/doc/html/rfc2616#section-19.3 https://datatracker.ietf.org/doc/html/rfc9112#section-2.2

> I'm hoping this is satire.

Me too. It's one thing to accept single LFs in protocols that expect CRLF, but sending single LFs is a bridge to far in my opinion. I'm really surprised most of the other replies to your comment currently seem to unironically support not complying with well-established protocol specifications under the misguided notion that it will somehow make things "simpler" or "easier" for developers.

I work on Kestrel which is an HTTP server for ASP.NET Core. Kestrel didn't support LF without a CR in HTTP/1.1 request headers until .NET 7 [1]. Thankfully, I'm unaware of any widely used HTTP client that even supports sending HTTP/1.1 requests without CRLF header endings, but we did eventually get reports of custom clients that used only LFs to terminate headers.

I admit that we should have recognized a single LF as a line terminator instead of just CRLF from the beginning like the spec suggests, but people using just LF instead of CRLF in their custom clients certainly did not make things any simpler or easier for me as an HTTP server developer. Initially, we wanted to be as strict as possible when parsing request headers to avoid possible HTTP request smuggling attacks. I don't think allowing LF termination really allows for smuggling, but it is something we had to consider.

I do not support even adding the option to terminate HTTP/1.1 request/response headers with single LFs in HttpClient/Kestrel. That's just asking for problems because it's so uncommon. There are clients and servers out there that will reject headers with single LFs while they all support CRLF. And if HTTP/1.1 is still being used in 2050 (which seems like a safe bet), I guarantee most clients and servers will still use CRLF header endings. Having multiple ways to represent the exact same thing does not make a protocol simpler or easier.

[1]: https://github.com/dotnet/aspnetcore/pull/43202

> Our browsers could have been exploiting things behind NAT this entire time. Smart TVs, Smart watches, phones, anything pingable on your LAN.

Maybe if they’re running an HTTP server (which isn’t too uncommon for IoT devices) while allowing the attacker website via CORS (less likely). An IoT device listening for WebSocket or WebRTC connections won’t benefit from CORS, but those are relatively rare and ought to have other mitigations in place.

All your links show is the ability to scan ports, not even read the responses to the fetch() requests made to local IP addresses. That could be useful to an attacker, but a far cry from exploiting any smart device or having the ability to send “outgoing crafted packets” from the browser. You cannot even open arbitrary sockets or craft arbitrary HTTP requests.

> The fact that most programming languages don’t give enough semantic information for their compiler to do a good job doesn’t mean it necessary has to be so. Functional programmers just trust that their compiler will properly optimize their code.

While everyone has to trust their compiler will make reasonable optimizations to some extent, there becomes a certain point of complexity where it becomes difficult to intuitively know if a "sufficiently smart compiler"[1] will properly optimize which is problematic.

I realize you're arguing Haskell is worse than Ocaml in this regard, but I'd argue it's harder to reason about how functional code will be translated into machine code than comparable procedural code in general.

[1]: https://prog21.dadgum.com/40.html

You need to resize the output grid to 6x6.

AFAIK, all Linux distros plus Windows and macOS have TCP keepalives off by default as mandated by the RFC 1122. Even when they are optionally turned on using SO_KEEPALIVE, the interval defaults to two hours because that is the minimum default interval allowed by spec. That can then be optionally reduced with something like /proc/sys/net/ipv4/tcp_keepalive_time (system wide) or TCP_KEEPIDLE (per socket).

By default, completely idle TCP connections will stay alive indefinitely from the perspective of both peers even if their physical connection is severed.

            Implementors MAY include "keep-alives" in their TCP
            implementations, although this practice is not universally
            accepted.  If keep-alives are included, the application MUST
            be able to turn them on or off for each TCP connection, and
            they MUST default to off.

            Keep-alive packets MUST only be sent when no data or
            acknowledgement packets have been received for the
            connection within an interval.  This interval MUST be
            configurable and MUST default to no less than two hours.

[0]: https://datatracker.ietf.org/doc/html/rfc1122#page-101

ASP.NET Core can easily route "/hello" to HelloController.Index(), but it's not exactly automatic. The controller library adds routes to the routing middleware in a call to MapControllerRoute the app developer must make during startup which specifies a pattern.

    app.MapControllerRoute(
        name: "default",
        pattern: "{controller=Home}/{action=Index}/{id?}");

https://learn.microsoft.com/en-us/aspnet/core/mvc/controller...

If you don't call one of the MapController methods, requests will not be routed to controllers even if they exist in the same project.

The iframe's sandbox attribute is doing a lot of work. I tried to change the parent window location to remove the footer, but the sandbox thwarted me since it didn't include "allow-same-origin".

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

Of course, you can just link directly to the URL the iframe points to. In the case of your video, you can simply visit https://smolsite.zip/s/57fe209faf4e6c0316ad32d7eeb792dfb571e... to have it autoplay while getting rid of the footer. I'm not sure how long the /s/ URL stays around before getting garbage collected by the server, but I bet you could regenerate it by sending a GET request to https://smolsite.zip/UEsDBBQAAgAIAPtxJlepozjzcAAAAIgAAAAKAAA... again.

The lack of server ALPN support on macOS is probably the extra friction you're referring to. This made accepting HTTP/2 connections with TLS impossible. Fortunately, support will be added in .NET 8 with https://github.com/dotnet/runtime/pull/79434.

They claimed they did support price caps the HN launch thread referenced in this new press release. They got a lot of praise for it in the comments back then.

> Max monthly spend: unexpected traffic spikes happen, and the thought of spending an unbounded amount of money in a month is really uncomfortable. You can configure fly.io apps with a max monthly budget, we'll suspend them when they hit that budget, and then re-enable them at the beginning of the next month.

https://news.ycombinator.com/item?id=22616857

`git reset HEAD~` doesn't feel like that much of a contortion to me. It's the destructive change that requires more contortion (`--hard`) which feels fair. Maybe this is stockholm syndrome though.

As mentioned elsewhere in this thread, with turn-based rotation units, this relationship can be simplified to avoid transcendental numbers entirely:

> (-1)^(2x) = cos(x) + i sin(x)

Why would you use QT signals for that? The point is you do not have to interact with the UI at that high of a frequency.

The snow itself also absorbs a lot of the sound.

It's possible to distinguish between past in future states if they exist in the same light cone. It says this in the wiki you linked to

> However, if the events are causally connected, precedence order is preserved in all frames of reference.

That's funny. The parent's NASA link uses the high relative velocities as "direct evidence for dark matter and supports the view that dark matter particles interact with each other only very weakly or not at all, apart from the pull of gravity." The lack of friction seems obvious with this view of limited interaction between dark matter particles.

.NET 7 improves this with static abstract members in interfaces and generic math.

https://github.com/dotnet/csharplang/issues/4436 https://devblogs.microsoft.com/dotnet/dotnet-7-generic-math/

> A reflexive pronoun is a pronoun that refers back to the subject of a sentence or clause. You can recognize a reflexive pronoun by its second half: they all end in -self or -selves. [...] Only the dual-purpose your* has two reflexive forms: singular yourself and plural yourselves. [...] But if you'd been typing in the late 1300s, themself would have been the default: it was the only version around until the mid-1400s. [...] Eventually, themselves became the only accepted form. But themself never fully disappeared.

https://www.merriam-webster.com/words-at-play/themself

Who said thermal information is not information? I'm not an expert, but isn't the problem that a black hole's temperature is directly proportional to its mass? I assume there's a lot more information about the thing falling into the black hole other than its mass which ends up getting lost.

Floating point math is IEEE 754 in pretty much all cases, so you should see this result in most languages. `math.log(1000, 10)` gives the same result because it's implemented using natural logs internally as it is in most languages.

In this case, there's only about six boundary cases to consider so you can just manually verify it works as expected.