kevinfat

I often hear the interest rates yielded this result of massive inflation or massive recession. But I'm not sure I believe that. I'm not convinced that the 0% interest rates lead to the massive inflation. So a non-mainstream economist Richard D. Wolff asked the elephant in the room question which no one seems to be asking which is to point out that we don't know how much of the price increases is simply due to companies just wanting to make more profit. And his point is how do you rule out that companies increased prices just for more profit irregardless of what the interest rates are?

That is wrong. Every description of rollback mentinos that. Replaying inputs after rolling back can result in a new state that is different from the client predictino which amounts to teleporting.

On more thought I don't see how what you're saying is relevant to my point. The server needs to maintain the current state (which is based on the latest input it has received). No matter how you do the networking rollback or not you can't escape latency causing a problem in perceiving the wrong state on the clients. Thats why with rollback players sometimes see the enemy teleporting. The networking code cannot remove the need for the player to "lead the shot" in some sense.

Ok interesting there is a lag compensation feature. I did not think of the server having something like that precisely because of what you mentioned it sounds like this is something the players can use to abuse or cheat with.

So consider a first person shooter with no rollback you're probably going to be aiming slightly ahead of the person to compensate for latency lag. And maybe you'll aim to the other side of the person if you think they changed direction before you saw it actually happen. Here because you feel the lag of your own movements you can take that into account in knowing how far ahead to shoot on the left side or the right side of your opponent.

With rollback if you guess they are going to continue moving in the same direction you just aim right on where you see them because of the prediction. If you think they are moving in the other direction you need to guess when they started moving in the other direction. That we are using rollback networking can't get rid of the need for you to guess this. To make that guess you'd like to know how far back they could have changed direction so you have some time interval in which to guess. From your perspective that time interval is based on the difference in time between the server's state now and the last server state you received. But my point is doesn't rollback make it impossible for you to know that while playing the game.

Whether you're using rollback or not you as the player need to know intuitively what is the time difference between the server's state and the latest server state received.

Question why is rollback networking good for games? To play devil's advocate with the lag hidden wouldn't this lead me to make decisions without considering the possibility that the opponent has already made a decision that is opposite of the prediction I'm seeing is.

With no rollback code then I feel the lag and can properly make decisions based on not only what I see right now but the exact amount of lag I'm feeling. How I play the game should be adjusted based on the latency of the lag. With rollback that feedback of the latency is hidden.

I don't think that is correct. I don't think the market actually needs phd level stats skills. Its just like the market doesn't need phd level pure math or doesn't need phd level CS. The number of situations where these specialized knowledge is useful in industry is vanishingly small. Having a phd is more about being even considered for an interview for such a position. The actual day to day knowledge used will consist of topics that even a person with a bachelor could require without putting in years.

So another way of saying this is consider the space of languages where

* control over memory use and layout (in contrast java is a pig over memory usage)

* some kind of easy way to use multicore (goroutines with channels or something else)

* speed, good cpu utilization

* garbage collected for ease of use

How many mainstream languages actually fit these criteria when Go came out? None? And how many fit these criteria now?

So for anyone reading this and seeing other comments about gain of function. The first thing you should realize is that the people here commenting about gain of function have no idea what they are talking about. They are completely clueless about micro biology and have never read any of the published papers that were labeled gain of function. For someone naive you would get the impression from the news that the research was a slam dunk obvious case of gain of function. But if you know some biology and actually looked at the papers then you know this really fuzzy and ambiguous and really does depend on how you define "gain of function".

To be a contrarian here to bring up a question, do these things really count? The roots of similar ideas already existed decades ago in old journals for all of these. Maybe the phrase "System Software Research is Irrelevant" could be interpreted as saying that all the big foundational ideas have all been found. The low hanging research is done and now its all iterating on details. Please tell me why this is incorrect?

Do any of them have details of how they built their news aggregator? For example, what infrastructure did they use to crawl, parse, and index the pages, etc.

In my mind the big advantage of Go over Node that is sometimes overlooked is that your code in Go is written in a largely serial manner with no callbacks. With Go you don't have to deal with a lot of callbacks when doing I/O since goroutines are multiplexed on the underlying threads.

Are any of these good for RTS games? Or is the overhead too much compared to a modified A* path finder that only finds close to optimal paths?

If I am understanding correctly the suggestion is to have a distributed hash table that any backend can lookup to find the other backend it should forward to. And since the distributed hash table is critically important persistent data I'm assuming that using something like Memcached is not a good idea? What would be advisable instead?

I've never dealt with Comet. I need the long detailed answer for complete noobs.

So in practical terms how does one setup backends to use WebSockets. For example, suppose you have nginx in front of a bunch of Unicorn or Rainbow processes and there are two clients that have made websocket connections. Consider a chat application. One of them sends a websocket message and the backend that receives it needs to push the message along the other websocket connection. But how does it know which backend to forward to? What is the intended idiomatic way of maintaining the necessary state?

Are WebSocket connections persistent to a single backend? That is, suppose Nginx is in front of two Unicorn processes.

Will Nginx maintain a mapping table of client browser connection to Unicorn process, so that messages will always hit the same Unicorn process? Does that mean the Unicorn processes don't behave in a "stateless" manner?

Then what happens to the websocket if a Unicorn process dies and is restarted? What does the client browser do? What does Nginx do? What happens to the websocket connections if Nginx dies and there is a failover to a backup Nginx instance?

Can someone explain, to people who know nothing about scaling infrastructure, why routing to idle dynos is a hard problem?

That's not a privacy issue. That's a I don't want feature X (ads) issue.

jquery and bootstrap are great for putting together a rails app really quick, but I wish there was a better way that didn't add bloat. I find that jquery and bootstrap add significant download latency to a webpage even if they are gzipped.