i was expecting a more hands on explanation of what the client sends and what the tracker responds but this post is quite abstract for a technical issue.
from what i read in the PR the qBT fix is to just ignore the proxy on the listening side of things but that doesnt explain the issue
i thought about including packet captures and some analysis on that, but ran out of steam. you're right that it would have made a more interesting post. maybe ill amend it at some point :)
there were other peculiarities i noticed in testing, like udp trackers not working through the socks proxy even after fixing the listening port problem. id like to revisit the topic at some point to see if that can be fixed as well.
I keep reading Rust is not that well suited for building game engines specially non-ECS ones. compared to C++ what did you find extra hard to implement in a performant way?
More traditional game engines tend to be a giant tangle of pointers with much more complex lifetimes than what Rust's borrows would allow. For example, the skeleton used to animate your character is reliant on a centralized hierarchy of transforms, which is deeply interwoven with physics, rendering, gameplay scripting, etc. These relationships and lifetimes is difficult or impossible to model with Rust's borrows, forcing the use of unsafe, and makes it harder to expose safe Rust interfaces to engine users due to Rust's aliasing rules around borrows and essentially forces the use of a scripting runtime. These factors also make it very hard to make performant multithreaded code without littering locks or channels everywhere, in any language or runtime, not just with Rust.
Bevy's ECS handles this by flattening these relationships. Instead of pointer chasing through the physics system to fetch rigidbodies which then point to the transforms, you expose the backing ECS memory as a query view: `Query<(&mut Transform, &Rigidbody)>` directly fetches all entities that have the two components without relying on one to hold a reference to the other. The lifetimes of the queried components is strictly bound to the surrounding function (a system in ECS terminology) by the borrow checker, and all of the unsafe used to create those borrows is neatly packaged behind the ECS crate boundary. This is so effective that the majority of Bevy's crates can have `forbid(unsafe_code)` enabled.
The downside here is that all of the complexity is now centralized into the bevy_ecs crate: there are many parts in it that are basically C written in Rust, but that does mean that we can focus all of our memory safety efforts on that one crate instead of making that collective responsibility of everyone in the ecosystem.
Of course, we do expose unsafe APIs from the ECS, but the use of this escape hatch explicitly demarcated, and generally you'll only see incremental performance improvements (no big-O algorithmic gains) over their safe variants. With the sole exception of `Query::get_unchecked_mut` allowing parallel access to mutable components that cannot be proven to be safe from static analysis (e.g. parallel hierarchy traversals), which enables parallelism where it otherwise would not be feasible.
desperate people do that. Scammer Altman went to Argentina during the peak economic crise of the century to make that offer.
likewise, most USA government backed benefits require people to submit all sorts of biometric to a private company who used to monetize coupons for military deployed personel, called gov.id or something.
back in 2009 in Spain we had what the author describes in Tuenti (https://en.m.wikipedia.org/wiki/Tuenti).
at first it was invite only and by default people's profiles were private, you'd need to be friends to see their activity and pictures.
your feed was just your friends statuses and new pictures in chronological order.
later on it got some games and a realtime chat but it ended up dying because of newer social networks.
it was great to keep your actual friends and family connected.
In Hungary, we had iWiW, one of the earliest "social media" sites. (=international who is who - though it never went really international, https://en.wikipedia.org/wiki/IWiW, started as WiW in 2002).
It was also invite based and it was exciting to get an invite back then. It was more like a phone book, it had detailed profiles where you could specify your favorite things, introduce yourself, upload a few pictures etc. It didn't have a newsfeed. Later they would introduce some kind of notification when someone uploaded new pics. But it was mainly "poll-based", i.e. you'd go to specific profiles to see if they uploaded anything new.
This was a significant break from the pseudonymous forum and chat culture (A/S/L?), and blended your real life with the previously totally separate online world for the first time. Now you could look up classmates, see who viewed your profile, of course it drove a lot of teen drama as you'd expect. It was a more public companion to the nascent MSN Messenger culture (which replaced the SMS-based more private teen comms culture, which replaced the family-landline-phone-based gossip culture and of course IRL-based one, feels weird to have lived through all those transitions - we didn't even have a family landline phone in the early 90s and would use phone booths to call family members in other cities).
The mainstream dominance of iWiW in Hungary was actually quite short-lived (~2004-2009), though it feels longer in my memory, there was so much happening, so much new stuff popping up. Note also that iWiW got bought by the local subsidiary of Deutsche Telekom already in 2006. So it was quite obvious that there's commercial value in such sites.
Initially Facebook was also more profile-focused, where the main activity was looking up profiles, checking their friends, reading bios, looking at galleries etc. (where you actually clicked links to explore, instead of being fed a feed and just scrolling), and the newsfeed-focus only got introduced later.
Nowadays, Facebook is mostly a public agora in Hungary, the platform for politicians and pundits and social critique etc (instead of Twitter like in other countries). I think the eager culture to post updates for real friends has dwindled, people are less naive about it and also realized they don't really care all that much about their second cousin's vacations or their old classmates' life updates. Real personal "social media" is mostly in private Whatsapp groups I think.
> people are less naive about it and also realized they don't really care all that much about their second cousin's vacations or their old classmates' life updates
Young people do care - but the "checking on friends" and "showing off my glamourous life/vacation" has moved to Instagram and Snapchat. Partly because Facebook is full of "old people" and thus less cool. As the Insta generation starts to have their own kids, those kids indubitably will look for another platform...
UV can trigger the chemical reactions within the plastics that yellow the plastics, but UV + peroxide does a different chemical reaction to bleach them.
but how does ethereum enforce that nodes run the scripts? right now it sounds like is just the protocol definition plus what normal node codebases do, but what if they dont want to?
All the code and calls to run it is stored on chain. When it's committed to chain every single validator node suppose not just record results of the execution, but run the code.
To host validator node you stake ETH which is serve as collateral in case your node misbehave, go offline, etc.
If specific validator cheats at any point and end up approving bogus data he'll be punished by loss of staked ETH and penalty grows with each attempt to cheat. If multiple validators commit the same bogus data they'll get even more severe punishment for coordinated attack on chain.
It doesn't take a supercomputer to host ETH node so there is absolutely no incentive to cheat unless you actual bad actor who is attempting 51% attack. And to perform said 50% attack you will need like $75-100B+ of ETH stacked since currently there is $150B of ETH stacked for Proof of Stake. So this kind of attack really doesn't make any financial sense.
reply