EarthLaunch
Joined 16 years ago
Joined 16 years ago
"If the crashes stop, the factory overclock is marginal; run a small negative offset."
This looks like it's saying: "If the crashes stop then we know the factory overclock is marginal." (This makes no sense.)
What it's trying to say is: "If the crashes stop then we can run a small negative offset, because the factory overlock is marginal."
What I would write: "If the crashes stop, we can avoid crashes by underclocking slightly. The speed difference between that and factory clock is marginal."
The people who can fix them are not in control. The org must be very top-down. But Steve Jobs had a top down style, so what's the difference? Its: Using and caring about the product.
It's top down direction with the people at the top not using/caring about the product. Presumably they're concerned with other things like efficiency, stocks, clout.
https://softwarecrisis.dev/letters/llmentalist/
Plus there's a gambling mechanic: Push the button, sometimes get things for free.
In my research I recall some potential tradeoffs with SSE [1], but even there I concluded they were minor enough to consider SSE vs WS a wash[2] even for my uses. Looking back at my bookmarks, I see that you were present in the threads I was reading, how cool. A couple WS advantages I am now recalling:
SSE is one-way, so for situations with lots of client-sent data, a second connection will have to be opened (with overhead). I think this came up for me since if a player is sending many events per second, you end up needing WS. I guess you're saying to use UDP, which makes sense, but has its own downsides (firewalls, WebRTC, WebTransport not ready).
Compression in SSE would be negotiated during the initial connection, I have to assume, so it wouldn't be possible to switch modes or mix in pre-compressed binary data without reconnecting or base64-ing binary. (My game sends a mix of custom binary data, JSON, and gzipped data which the browser can decompress natively.)
Edit: Another thing I'm remembering now is order of events. Because WS is a single connection and data stream, it avoids network related race conditions; data is sent and received in the programmatically defined sequence.
0: https://news.ycombinator.com/item?id=43657717
1: https://rxdb.info/articles/websockets-sse-polling-webrtc-web...
- What makes load balancing easier with SSE? I imagine that balancing reconnects would work similar to WS.
- Compression might be a disadvantage for binary data, which WS specializes in.
- Browser inspection of SSE does sound amazing.
- Mobile duplex antenna is way outside my wheelhouse, sounds interesting.
Can you see any situation in which websockets would be advantageous? I know that SSE has some gotchas itself, such as limited connections (6) per browser. I also wonder about the nature of memory and CPU usage for serving many clients on WS vs SSE.
I have a browser game (few players) using vanilla WS.
The practical solution: Manually toggle it.
My favorite solution: Start the comment with a curse word.
I'm a game dev and often need to avoid situations where I'm using '.map' to iterate an entire array, for performance reasons. It would feel odd to use the concept, knowing it wasn't really iterating and/or was using an index. Is that how it works?
> But how do people feel about these topics
I find it notable that tokens don't necessarily express people's feelings. Put another way, tokens aren't how people feel, they're how they write.
Samstave mentioned in this thread that Twitter is a 'global sentiment engine'. I'm sure that's literally true. Sentiment measurement is only accurate to the degree that people are expressing their real feelings via tokens. I can imagine various psychological and political reasons for a discrepancy.
If you did sentiment analysis of publicly known writings of North Korean administrators, would that represent their feelings?
I think the interplay with free speech is interesting here: In a setting where people feel socially and legally safe to express their true opinion, sentiment analysis will be more accurate.