The "satisfies" keyword may be what you are missing. Most of the cases I used to need "as" (usually weirdly permissive types from some lib) can be nudged in line with a "satisfies"
> Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago.
This is only true for games that can replicate their entire state in each packet.
There are many situations where this is infeasible and so you may be replicating diffs of the state, partial state, or even replicating the player inputs instead of any state at all.
In those cases the "latest" packet is not necessarily enough, the "timliness" property does not quite cover the requirements, and like with most things, it's a "it depends".
Is there a relationship with the "Build" component of Knative here? ... It seems they were working on a very similar abstraction of CI/CD... This seems like a more general abstraction of the same problem
I'm really happy Google are giving a go at making ChromeOS into something more than browser on steroids. I really believe this is a path to a decent Linux Desktop future.
I'm def considering getting a pixelbook for my main machine this year now.
You do, and xiwi (X11 in a window) is almost magic in letting me spawn a proper terminal emulator integrated with ChromeOS's window manager (Aura?).
...but it feels like a bit of a hack. I have to have the laptop in dev mode and there's a slight fear that an automatic update might prevent the chroot from working, or that my stateful downloads directory might disappear.
My thought was that ChromeOS is kinda where OS X 10.0 was... a great UI on top of a great base that just works. That's what drove many of us to Apple when we got bored of re-configuring linux, it's what made many of us recommend Apple to friends/family.... Apple have dropped the ball, Google is in a pretty good place to pick it up.
As surprised as I am to say this; I think Google could steal a large chunk of the developer market overnight with some slight changes to Chrome OS.
I needed an emergency machine last week (My 2011 Pro finally died), and I opt'd for a £200 Chromebook (EDGAR), thinking all I need is a browser and a terminal right this second and I'd worry about what Apple is doing later.
A solid Linux laptop with working sleep, working wifi, great battery life. Tad underpowered but hey it's £200. I'm _really_ impressed.
If Google relaxed the constraints a little on the OS, or supported a Crouton-like workflow for containers without having to stick it in dev-mode, they could make A LOT of developers very happy.
I like how the Signal app (at least on Android) also works for insecure SMS to give me one place for messaging... well apart from everyone who uses WhatsApp at least.
What I'd love is if they could also make it an email client too. Letting me send/receive insecure emails or (if the recipient has Signal) encrypted email using the same key management. I'd much prefur to give out an email address (totally in my control) than a phone number (could be taken away from me at any moment).
> His prediction was that everyone would dress in uniforms. But that’s the complete opposite of what has happened. And I don’t think people will be dressing in uniforms anytime soon.
OK, here's a potential prediction that could bring about "uniforms"...
If we end up with some kind of ubiquitous augmented reality, we may end up styling ourselves like you would a game avatar, and even "themeing" everyone around us. In that world, it might make more sense to just all wear comfy grey onezies all day.
Of course all predictions like this are hilariously off... it'll probably be more like the entire earth bizarrely becomes a comfortable 23C and everyone just walks around in socks.
My bedtime reading recently has been Propagator Networks[1][2][3] ... and I keep daydreaming of a resource management system just like Dave describes in this video... I do believe "mostly correct" computing is going to play a big role in the future.
I don't see anywhere in the bill what EXACTLY an Internet Connection Record is, and since there is no such thing as a standard Internet Connection Record in any of our existing network infrastructure, I assume this has been left vague so that it can be extended to whatever they want.
Nor does it define the exact kind of Internet Service Provider that the law is suppose to be enforced against. (Is this only suppose to apply to those supplying bandwidth or do all websites/services count?).
> Law enforcement agencies would not be able to make a request for the purpose of determining – for example – whether someone had visited a mental health website, a medical website or even a news website.
This seems to imply that there must be a whitelist of domains for which ICR collection is required. But there is no mention of such a list nor how it would be curated.
Whenever I see those sorts of limitation I assume there's probably some kind of poorly handled escape situation to exploit and their fix was "well just don't allow that pesky < character"
There's a guy in Brighton (UK) with one of these... he always looks so happy and surprisingly stable on it.
It seems to make up the relatively steep hill I live on, but I've never seen him use it to go down the hill. Guessing it gets bit sketchy fighting gravity.
No the contexts in pools do not share any state. Once you call an Eval from Go-land you'll be tied to context until that Eval returns, but Go-land will yield during that time so other goroutines(/contexts) are free to execute. It's just a convenience for setting up and working with multiple contexts to take advantage of multiple cores. Probably better to think of it like a process-pool.
The use case I had was along the lines of:
* Bind/Expose a bunch of Go functions to N JS worker contexts.
* Execute a large queue of JS-functions using the workers.
Spidermonkey did actually have a way to do a kind of shallow copy of a context and save/restore stack, which shared state, however this actually ended up making things much slower for my use as it required locking the threads and constantly copying stacks.
I built a package to bridge spidermonkey/Go last year[0]. I ended up doing most of the communication via JSON (after several less stable versions using reflect) which was fine for the use-case I had. Unfortunately since it builds spidermonkey and some wrapper code it ruined any chance of "go get" working cleanly which doesn't make it a very attractive package.