Some people may not see the use case, but the popularity of SNAP has shown that there is a user base for this product. What's interesting to me is Facebook's decision to completely copy the use case in an attempt to capture the market. They've tried to do so with Instagram Stories & DMs, as referenced to by the post, but I'm curious about the rationale to make it a standalone app, which would hurt adoption.
I suppose the idea is the entry point - Instagram's entry point is viewing content, not creating content (the feed is the first thing that shows up when opening the app). Threads is the same as SNAP in that the first entrypoint is to create content: it opens the camera.
It'll be interesting to see if this can succeed in finally pushing SNAP out, as one benefit for users is leveraging the existing social graph from Instagram, whereas you must add people for SNAP.
I recently graduated with a BSc in Computer Science, and have 16 months of internship experience under my belt. I have mostly done front end work in my internships, but I am also interested in distributed systems (took a graduate course in the subject last term).
From my memory, this is meant to be more introductory material for people first learning computer science, rather than a guide for people who are attempting to learn a lisp. My school (UBC) uses Racket and this book as the intro level CS course.
Speaking as someone who's graduating this year, I wasn't exposed to it at all in my undergrad. I might be covered in one or two upper levels, but I hadn't heard of it until taking a graduate course where we talked about verification.
You can remove Pocket from the address bar. All you do is right click it and the only option shows up as "Remove from address bar", so you don't have to stare at the reminder if you don't want to!
I'm surprised they felt confident enough to lift a lot of the restrictions so soon. A lot of them seemed like big game changers I wouldn't expect the ai to be able to exploit so easily. Especially the introduction of Roshan and invisibility, they mention implementing some randomization, it seems like it would take quite a big commitment in terms of resources to take Roshan where the AI wouldn't even realize the benefits immediately (namely the Aegis, the XP and gold they would have to value against the loss from farming/taking towers).
The introduction of the other heroes also comes as a surprise, I wouldn't have expected them to have the ai utilizing new abilities. They don't mentioned how they are picked, other than the ai having a random draft of them (does the ai pick their composition?)
I wonder if the reward mechanisms factor in denying resources from the enemy team. A lot of the time it makes sense to take Roshan just so the enemy doesn't get the opportunity to.
I think that'd be an even harder behavior for the ai to come to though, since they'd have to recognize those benefits for the other team and their origin, and then finding that taking Roshan prevents those benefits. I think that's a next step after discovering the benefit of taking Roshan.
Same argument applies to pushing and defending towers, getting rax etc. Assuming that the devs did not hardcode rewards for those objectives, then the AI surely already has to 'understand' events that impact the game in long term.
I think you're right about it being more about denying the enemy team. IIRC, in the last update they said that the bots tend to prioritize denying creeps and taking objectives over getting perfect last hits in lane.
I had a conversation with a friend about this, and the outcome was the idea that BGP could be extended with functionality for this case. There needs to be a way to brand "negative" traffic or routes advertised with some sort of reputation system. In the event of a DDoS attack coming from an AS, you could have intra-AS weight for any given AS such that if an AS reports malicious traffic from a route, it's given a lower weight and traffic is less likely to route to that AS in favor of a less specific prefix. This would encourage any given AS to act in desirable ways, as their actions (or actions coming from within them, e.g. a customer of theirs being the source of a DoS attack) would have consequences.
How would that work in practice? If I compromise a pile of IoT devices running on Comcast users' networks, and use them to launch and attack, all Comcast users on their subnet get marked as uncool? And if we're marking them as "bad", doesn't that mean all of their BGP peers mark them as uncool and then the weights for their prefix are lower but still even, so routing still ends up the same?
The only way they'd be impacted would be if some networks didn't implement your bad-actor-prefix-weight-mod, and then we'd just be penalizing the people who don't use your system along with the attackers, since we'd be routing the bad traffic via their networks.
You can see the impact of this kind of thinking in RBLs and blocklists - try to send email via your residential connection and you probably won't be able to.
From my memory, creates an object, gets all the other active nodes in the cluster, moves them to that node and then back to the original node, showcasing the object passing feature of the language.
I recently took a compilers course from Hutchinson, and he talked a bit about the design behind object passing in Emerald from a compilers point of view, how once you have garbage collection, it's easy to implement moving objects between nodes of programs. Interesting concept that I was surprised to find wasn't as commonplace!
One issue is that at scale, communication costs dwarf almost every other cost. So, sending objects between nodes isn't as critical as you might think it is for distributed systems.
(I was also in Norm's class! It was awesome, and also got me over the Rust hype to some degree)
I guess he means that you don't need speed for distributed applications, which is a bit misquided because nobody said you did, and that's not what Rust claims to do well.
Oftentimes the biggest cost associated with communication is latency, and the one thing that hasn't changed over the past few decades is the speed of light.
Garbage collection isn’t absolutely necessary with lifetime/liveness or explicit frees. Furthermore, at scale in production, if a GC were absolutely necessary, then it’s vital to have a concurrent, incremental collector like c4 because GC 30 sec pauses and sharding up app servers with 2 GiB heaps is unacceptable in the real world.
The article says that it was first posted on Reddit, but nobody noticed for a while. The Github copy is almost certainly a repost, by a different author than the original leak.
"This source code first surfaced last year, posted by a Reddit user called “apple_internals” on the Jailbreak subreddit. That post didn’t get much attention since the user was new and didn’t have enough Reddit karma; the post was quickly buried. Its new availability on GitHub..."
I suppose the idea is the entry point - Instagram's entry point is viewing content, not creating content (the feed is the first thing that shows up when opening the app). Threads is the same as SNAP in that the first entrypoint is to create content: it opens the camera.
It'll be interesting to see if this can succeed in finally pushing SNAP out, as one benefit for users is leveraging the existing social graph from Instagram, whereas you must add people for SNAP.