You will notice in that guidance that if you subsequently fall ill as a casual (sub 15 min) contact they will need to talk to you for contacts tracing..
So that implies there is a health risk burden under 15 which needs to incur costs of contact tracing at which time this app cannot help.
That happens to be how common browsers have implemented it but the spec does not guarantee it:
> Let handle be a user-agent-defined integer that is greater than zero that will identify the timeout to be set by this call in the list of active timers.
Well, due to a bug in a specific version of vi, holding the space-bar for a few seconds causes the laptop to overheat.
I bought an external thermometer that connects via USB, and I have a daemon that monitors it to notice the overheating and send the ESC key to the application.
Ctrl+c is technically not quite the same as Esc: it doesn't trigger InsertLeave autocmds, and doesn't finish abbreviations. But as long as you don't have those you'll be fine.
This is the part that I find somewhat unfortunate about Peertube. This means that only ActivityPub clients that support WebRTC will be able to access Peertube media. Right now, I think this basically means just modern web browsers. It bothers me somewhat that an early, potentially major ActivityPub service is going to limit full functionality to the few existing major web browsers. That's the opposite of what I want from a federated protocol. (Someone correct me if I've got any of this wrong.)
Regardless, Peertube seems awesome, and I hope we keep seeing more and more services built on ActivityPub.
ActivityPub defines federation messages server to server and client to server. It is not a protocol per se, and rather a message exchange standard, which could perfectly be used only between servers, as is the case with federation of videos between PeerTube instances, and more recently for video comment feeds, that can interact with the larger fediverse (Hubzilla and Mastodon so far were tested).
In no way it defines how you access media. That is defined by the use of WebRTC, which is supported by a growing number of browsers, and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
> and anyway provides a fallback to direct streaming (HTTP), so that any browser can interact.
Ah, that's awesome. That definitely assuages my fears somewhat.
> [ActivityPub] In no way it defines how you access media.
ActivityStreams (which ActivityPub builds on) does define an attachment property for messages [1]. Is this not a standard mechanism for clients to access ActivityPub media (via the attachment's type and url)?
It is, but I don't see how web browsers would need to interact directly with ActivityPub. That's just a way to settle on a json structure everyone will be using in their web application (that acts as AP client), as is the case in Mastodon.
Here with PeerTube the client interface doesn't interact with AP to watch videos or get them. It just requests the list directly to the server.
WebRTC libraries exist outside of browsers. What video-capable software are you hoping to use this with that isn't a browser and isn't able to be wired up to a library?
My concern isn't about any current AP clients; it's that we'd be cutting off a whole dearth of potential future AP clients by making it the general expectation that all viable AP clients support WebRTC, and thus the task of building a client goes from the relatively simple "support json over http" to "support those + WebTorrent/WebRTC", which (despite what you say) isn't trivial (unless the client is in-browser/webview). Even if "just hook up a library" were a viable solution, the requisite increase in complexity/LOC/bugs would be really unfortunate. If this were the case, it seems to me we'd lose a lot of potential future diversity in AP clients.
I'm having trouble finding any complete WebRTC implementations outside of browsers, do you have any examples?
I guess it depends on whether "if" is treated as an expression which returns a value, which I don't think is the case due to the fact that I don't think there is an implicit value return in JS (such as in Ruby; the final line in any scope is the value that scope returns; same as in Elixir)
There is at least one very large bank (which I won't name) who is unable to move off ie6 for some internal apps which to my knowledge are still using this in some backoffices even today.... At least two years ago they were paying Microsoft less money than a rewrite would cost to support it so it kind of makes sense....
I only found that bad boy out after disabling some ciphers on some loadies which broke a lot of their stuff....
That is an interesting parting phrase. I suppose on that level where he's coming to grips with only have 30 days, he must be rationalizing that today is the first of those, and that he'll at least get the 30... Heavy.
I can't even imagine the understanding of my own mortality where I could say "See you tomorrow... Maybe." and actually mean it.
I don't know how. But one way I can think of is to not make any long-term plans.
All your plans and goals can be achieved in one day. You finish the day reaching your goals. You wake up next day, find yourself alive, you make new goals for that day only.
Yeah I agree with this. I seem to have reached a point in life where I don't really think about the past and future often, but I wouldn't say I've quite reached enlightenment yet.
There seem to be a few paths, but if I were you I would stick to the ones expounded by the true spiritual geniuses of our species- Jesus and the Buddha. Maybe Mohammed- I don't know enough to say one way or the other.
"Live every day like it's your last. That's what they tell you, right? Yeah. What they don't tell you is what to do when it gets to tomorrow and you're not dead yet. You got bills to pay...." - Doug Stanhope.
He does suggest you ask a few questions to the person you've developed a relationship with, including: "Who are the other individuals in your organization that you suggest I meet?".
That doesn't stop the app from prompting for the in-app purchases, it just prevents unwanted transactions.
Go download Talking Tom (it's "free") and see what parents complain about. Turning off purchasing doesn't stop my 2 year old from hitting one of three or four "upgrade" buttons available on screen at any given moment, bringing up a popup or opening a browser or the app store for cross promotions. I would have actually bought the damn thing because of the entertainment it provides if it weren't for refusing to support the total sleaziness of that monetization method.
I don't know if that will help. You can already lock down iOS pretty tightly for kids. It's the apps themselves that are the problem.
There's just a huge, annoying trend of making apps crippled or annoyware until you buy some ridiculous IAP. AFAIK, that situation is not much different on Kindle/Android.
https://www.health.gov.au/sites/default/files/documents/2020...