HN user

dbrueck

1,672 karma

contact me on gmail: dave dot brueck at

Posts0
Comments447
View on HN
No posts found.

Interesting! It's worth noting though that HTTP actually works very well for reliably downloading large immutable files.

And since this proposed protocol operates over TCP, there's relatively little that can be done to achieve the performance goals vs what you can already do with HTTP.

And because "everything" already speaks HTTP, you can get pretty close to max performance just via client side intelligence talking to existing backend infrastructure, so there's no need to try to get people to adopt a new protocol. Modern CDNs have gobs of endpoints worldwide.

A relatively simple client can do enough range requests in parallel to saturate typical last-mile pipes, and more intelligent clients can do fancy things to get max performance.

For example, some clients will do range requests against all IPs returned from DNS resolution to detect which servers are "closer" or less busy, and for really large downloads, they'll repeat this throughout the download to constantly meander towards the fastest sources. Another variation (which might be less common these days), is if the initial response is a redirect, it may imply redirects are being used as a load distribution mechanism, so again clients can ask again throughout the download to see if a different set of servers gets offered up as potentially faster sources. Again, all of this works today with plain old HTTP.

Sorry for not being more clear, I was referring to the advertising or promotion that comes via the elite players. Take Valorant, for example. Riot Games leveraged their League of Legends user base and gave early access to high-end players and that apparently played a big part in helping its popularity take off. Now it has a robust presence in eSports, again helped by the high-end players.

It's not uncommon now for popular professional streamers to get early access to new features/modes because the game companies know that those players can help build or retain the player base.

Relevancy filtering is more for network traffic optimization, it doesn't really help with cheating in most cases. In a FPS, for example, the actors the cheater most wants to know about are almost always also network relevant.

But taking a step back, for fast games (like an FPS), the latency requirements drive you to send semi-secret info to the client (like the positions of other players), and so that's where things start to break down. But the traffic in the other direction is a problem too, as you have all of the scenarios in which the messages to the server (e.g. aim info, timing of weapon of firing) can be spoofed or engineered.

The motivation for the client-side anti-cheat systems is to extend as far as possible the envelope of what is considered trustworthy - i.e. if they can't solve the latency problem, then they try to make the client more trusted.

It's impossible to completely solve the problem, so it's about finding a solution that solves as much of the problem as possible. Unfortunately the main thing going for kernel anti-cheat is that most users don't care that they have to let someone root their machines to play a game, though the tide would likely turn if there were a high publicity exploit.

The anti-cheat problem is long-running and complicated. If you choose not to run anti-cheat because you understand that these are opaque rootkits, good for you! That's a totally, 100% valid choice. But please keep in mind:

  - you are a tiny minority and not the target customer
  - online multiplayer games are an absurdly big business (i.e. there are huge incentives here)
  - no, you can't completely solve this server side
  - elite players are insanely good - they are by definition outliers, so looking for statistical outliers is not in itself a solution
  - game companies are highly incentivized to work with (or at least not antagonize) the elite players (so just throwing them in matches with cheaters is not a solution)
  - the stakes are high both for the devs and their users, so "pretty good" anti-cheat is usually insufficient
You can sum things up by saying that kernel-level anti-cheat DRM is the worst solution, except for all of the other solutions.

I hope to see more discussion on possible solutions and tradeoffs - this is a challenging technical problem whose solution (if there is one) is fairly valuable.

[edit: hopefully fixed the tone, per feedback]

It's fun to experiment and try out ideas - kudos to the author for doing this and sharing the results with the community, I love that.

As far as the results go, though, I don't see any realistic scenario where this is a net win vs a symlink. :)

Not the OP, but the appeal of languages like JS has a lot to do with developer productivity. I write gobs of JS and Python code and the finished programs and libraries can be strongly and statically typed end-to-end. I just don't want to be forced to do it in cases when it doesn't really make a difference, and I don't want to waste time on it when I'm still figuring out the design.

My hope is one of the Next Big Things in programming languages is the widespread adoption of incremental typing systems.

So during the early stages of dev you get the productivity benefits of dynamic and loose/duck typing as much as you want, and then as the code matures - as the design firms up - you begin layering in the type information on different parts of the program (and hopefully the toolset gives you a jump start by suggesting a lot of this type info for you, or maybe you specify it only in places where the type info can't be deduced).

Then those parts of the program (and hopefully eventually the entire program) are strongly and statically typed, and you get all of the associated goodies.

Honestly this feels like an indictment of privatizing space travel

NASA has involved the private sector for over half a century. Taking that out of the equation leaves you with SpaceX absolutely killing it and Boeing bumbling along despite getting bigger contracts from the government, so it's hard for me to draw this same conclusion.

a benefactor with unbelievable wealth being able to hoard the best engineers

Hmm.. the implication here doesn't ring true at all. "Oh how I wish I could work at Boeing where all the real innovation happens, but here I am stuck at SpaceX due to these darn golden handcuffs". I hope SpaceX people get paid a lot, but I suspect the draw for most is what they are doing and the speed at which they are doing it.

The interconnection of “the divine” and science was central to the scientific revolution

Agreed. Even today, for many people there is no fatal tension between science and religion (often in large part because they serve to answer different questions).

My personal rule of thumb is that if I see an apparent contradiction between religion and science, it just means I have an incorrect/incomplete understanding of some area of religion or science (or both).

Chunked transfer encoding can be a pain, but it's a reasonable solution to several problems: when the response is too big to fit into memory, when the response size is unknown by the HTTP library, when the response size is unknown by the caller of the HTTP library, or when the response doesn't have a total size at all (never-ending data stream).

Agreed, and so far the replies to your question are (for me at least) deeply unsatisfying. We already had SSR back in the CGI days, and it was awesome when we moved a lot of that stuff to the client. I know this is all a giant Wheel of Time, but I'm not ready for us to go back just yet. :)

SSR to help with page loading seems like a poor reason. I'm sure there are exceptions, but so many sites make gobs of requests for bazillions of elements (trackers, ads, etc.) anyway. Seems like there is lower hanging fruit we should check out first.

Doing it for SEO just makes me sad - a major architectural change just to try to keep up in the never-ending chase to make Google happy is depressing.

The big upside in moving dynamic rendering to the client for me was that it then made it far easier to have a cleaner separation of duties between a web designer and a developer. You take a graphical designer and have them master HTML/CSS and they can then create the initial design, make it into valid HTML/CSS files, be responsible for things like site responsiveness on different screen sizes, browser quirks, most of accessibility tasks, etc. The developer's job is to "wire it up" - things like populating the data, making the site react to user input, and so forth.

The big win was that this division of labor is not only enabled at the outset, but it is relatively easy to maintain through the entire life of the site. We had tons of sites where there were design refreshes with little (and in a few cases, no) developer work. When I see SSR tools now (as well as client frameworks that chop up the HTML into chunks and then intertwine them with code) my first impulse is to wonder how that gets maintained and updated. Like, when the UI is redesigned and reorganized, does all of that code have to be rewritten? When something doesn't work right on Safari, can the web designer help much or is it all on the shoulders of the dev?

Oh, I thoroughly understand the parent's point, I'm just disagreeing that it is a problem that needs to be "addressed".

Most language design decisions involve tradeoffs, and for me this one has been a big positive, and the potential negatives have been - across decades of active usage - almost entirely theoretical.

Also, the real-world use case for importing code and auto formatting it is quite doable with Python - the main thing you can't do is blindly (unintelligently) merge two text buffers and expect it to work every time, but in general it takes only a smidgen of analysis on the incoming text to be able to auto reformat it to match your own. You could go all the way and parse and reformat it as needed, but much simpler/dumber approaches work just as well.

What you can't do is take invalid Python code and expect it to autoformat properly, but that borders on tautological, so... :)

Whitespace is semantically significant in nearly all modern programming languages, the difference is that with Python it is completely significant for both the humans and the tools - it is syntactically significant.

I've actively used Python for a quarter of a century (solo, with small teams, with large teams, and with whole dev orgs) and the number of times that not having redundant block delimiters has caused problems is vanishingly small and, interestingly, is on par with the number of times I've had problems with redundant block delimiters getting out of sync, i.e. some variation of

  if (a > b)
    i++;
    j++;
Anytime I switch from Python to another language for awhile, one of the first annoying things is the need to add braces everywhere, and it really rubs because you are reminded how unnecessary they are.

Anyway, you can always write #end if you'd like. ;-)

A lot of happy memories playing this game on a knockoff Apple II+.

To this day it's still impressive to me that they got 3D wireframe rendering (with hidden line removal!!) working on a 1 Mhz 6502 chip - that thing doesn't even have multiply and divide instructions.

I'd be willing to bet that a lot of it is influenced by context and expectations.

Take one of those images, put it in a nice frame, hang it in a quiet art museum, stick a little placard on the wall next to it with a made up backstory, and your emotional response will probably differ.

Conversely, go to your local art museum and randomly pick 10 paintings. Take a hi-res picture of each and place them on a web page entitled, "AI is getting better at generating art" and you'll probably pick out a bunch of tell-tale flaws that are evidence of machine-generate pictures. :)