What really reinforced this for me was learning to what lengths some hedge funds are willing to go to get an edge. Case in point: buying GIS data on major retailer's parking lots to get a feel for holiday earnings. No retail investor is ever going to be able to match that kind of Intel, ever.
I buy index funds and leave the majority of my money there but allow myself to make small bets on trends in the market that I think will play over long periods. Sometimes it works, like buying lithium stocks in the 2010s and other times it sucks and doesn't, like buying solar stocks in the 2010s and watching the entire industry get shredded to pieces in the last 5 years.
Small speculators do have an advantage in that the market is much more liquid for them. If your position is $1k you can buy and sell without moving the market noticeably. If it's $1bn, not so much.
yeah vast majority is just index funds but I just had to prove to myself than I'm an idiot, so there's a separate account with a tiny bit of money in it that I get to play with. Sometimes you buy GME, sometimes you buy SVB.
You don't have to trade against the firms, retail can make up the majority of some markets (e.g not on dark pools etc..), you just have to beat them and join the firms in taking their money. It's far more difficult than buying an index but it is not a scam just because it is hard and most people don't know what they're doing.
Edit to clarify: my portfolio is almost all index funds to clarify, and that is what you should do too, but I'm just saying it is entirely possible to trade and it is a skill. Something can be somewhat like gambling and yet still have elements of skill just like poker.
The Unity SDK is C# and slots right into the typical Unity patterns for touch input.
Two contact types are provided:
Finger – Representing a single touch point, e.g, a finger
Glyph – Representing a tangible object
For each contact, you get ID, Position, and Phase. For Glyphs, you also get orientation and touched status, as in the system knows whether the object is being touched or not. There tunable parameters for the tracking system as well.
For event systems (e.g., menus, etc), BoardUIInputModule in provided in place of Unity's default InputSystemUIInputModule.
That's the point he is making. QUIC has to be based on UDP because the networking stack is ossified enough to not allow the addition of any new Layer 4 protocol. It's not a huge drawback though.
I think they’re saying that due to how firewalls are deployed, everything end up either being built on tcp or udp, instead of using existing (or building new) layer four protocols more suited to solving the problem like sctp, et al.
I’m not sure I agree though, because many firewalls already pass other protocols today, like GRE, IPSEC, etc.
That is exactly my point, thank you for clarifying. And yes IPSEC had started forcing people to open up their firewalls. If I had my way though it would be the other way around: all IP protocol numbers except those specifically deemed obsolete or insecure should be allowed, including a range for user defined custom protocols. We really painted ourselves into a corner of 6s and 17s.
Their point is that's a sad design choice, caused by firewalls forcing QUIC to take a first-class TCP-like internet protocol and wrap it with encrypted headers inside UDP for the sole purpose of preventing firewalls from blocking it or making it break in myriad subtle ways. Even QUICs unencrypted header parts are designed to be difficult for intermediate network equipment to track and modify, because of their history of making other protocols over TCP unreliable by doing this.
SCTP is another high-performance protocol that provides many of the same network and performance features as QUIC, but it has been around for ~25 years. It was widely implemented. It was even in Linux 2.4 and available for Windows XP and MacOS. WebRTC in browsers can use SCTP, which makes sense (it predates QUIC) but is actually a bit of a problem if you want wide interoperability with WebRTC.
But despite SCTP being around and widely implemented, and doing many of the good things QUIC does, SCTP was never widely adopted, nor seriously considered for HTTP, mainly because of the problem of firewalls. (And to be fair, some operating system API limitations).
Basically, if TCP were invented today, it could not be deployed succesfully over much of the internet unless it was wrapped in UDP and encrypted.
UDP-with-encryption is now playing the role that the IP protocol is supposed to play, just because too many firewalls block nearly every IP packet that doesn't have type TCP or UDP. If UDP is used but without encryption for a popular protocol, eventually too many firewalls deep-packet-inspect that UDP protocol too, and do the same kinds of blocking, tampering or making protocols break.
There are some downsides to QUIC's ossification resistance. I did some work for a mobile equipment manufacter who adaptively manage the queues for multiple TCP streams from different users and different applications from the same user, to help ensure a better, fairer and lower-latency experience. QUICs properties made it difficult to measure what's going on at the protocol level, forcing the queue management to use crude statistical estimators instead, which don't work well on bursty protocols.
UDP is playing exactly the role it was intended to play. Apart from saving 8 bytes of header and a checksum, what's the advantage to running the protocol directly on top of IP? How is this "ossification"? Again: this was David Reed's original design purpose for UDP! It was exactly for doing shit on top of IP without having to run through TCP's mechanism.
Hi, I'm not literally suggesting those are the only important instruments. People sometimes truncate examples in suggestions. The assumption is that if someone likes the idea, they could extend the pattern.
I will give you the benefit of the doubt and interpret your comment as not specifically accusatory towards Carmack:
Report someone to HR who deserves to be reported to HR, not someone who gave genuine good-faith (and in this case, correct) technical feedback that unfortunately got in the way of someone else's promo packet / empire building.
There are certainly good reasons to report someone to HR. This is not one of them. Only toxic workplaces tolerate such pettiness. And ultimately, XROS was canned by Boz anyways.
reply