I think a country bar/dance hall/saloon is unique in this regard when it comes to social dancing destinations.

They are certainly not for everyone but I have yet to have found another type of social dancing venue that balances being a hangout spot and a place to dance.

Line dancing in particular brings something to the table outside of couples dancing that gives those not interested in the potentially-unfamiliar social situation of dancing with someone else a reason to go. I think that especially helps to keep these communities going.

Quick plug: I've been trying to catalog country venues (and their dances and songs) at https://dancedocket.com

Not quite standardized, but Firefox appears to allow extension-less screensharing as of FF 52

https://wiki.mozilla.org/Screensharing

https://mozilla.github.io/webrtc-landing/gum_test.html

This is all done with parameters specified to getUserMedia as opposed to Chrome's extension-only "chrome.desktopCapture.chooseDesktopMedia"

As far as I can tell, the reason why screen-sharing is not more widely accessible is because of a security UX issue rather than a technical limitation. Both Firefox and Chrome are can provide you with media stream ID's to use in WebRTC negotiation, they differ mostly in the boundaries required to authorize access.

For people already used to org-mode + curl (or any CLI tool), I highly recommend using those together when exploring an API (granted, this involves throwing simplicity out the window)

  :PROPERTIES:
  :header-args: shell :var PASSWORD=not :var USERNAME=narb :var AUTH_URL="nova.example.com:5000/v2.0/tokens"
  :END:
  ...
  #+NAME: get-openstack-token
  #+BEGIN_SRC shell :cache yes :results verbatim
  export DATA='{
      "auth" : {
          "tenantName": "'"$TENANT_NAME"'",
          "passwordCredentials": {
              "username": "'"$USERNAME"'",
              "password": "'"$PASSWORD"'"
          }
      }
  }'
  curl -s $AUTH_URL \
      -H "Content-Type: application/json" \
      --data "$DATA" | jq -r ".access.token.id"
  #+END_SRC

  #+RESULTS[be67...]: get-openstack-token
  : deadbeefdeadbeefdeadbeef

  ...
  #+BEGIN_SRC shell :var AUTH_TOKEN=get-openstack-token
  curl -H "X-AUTH-TOKEN: $AUTH_TOKEN"
  ...

Not to discount tools such as postman / insomnia or other built-in editor tools like restclient-mode, they are all fantastic tools

Some quick reasons why I found this works best for me:

* Org-mode is already great as a dedicated note-taking tool

* This is immediately compatible with existing CLI examples or output from tools that offer 'export as cURL' -- this is especially useful if I want to reverse engineer an api request by browser is making

* Easy to export to an html/wiki document for immediate consumption by others with working CLI examples

* Composable with other CLI tools like jq and xmllint

* Plain-text files are easy to version control

Instead of org and curl, some might like to give restclient a call. You put a # comment, then a rest call and maybe some data. It's still organized like a notebook, though, so you can point to any call and punch Ctrl-return and the result pops up in another buffer. Simple and slick without all the Org markup.

https://github.com/pashky/restclient.el

Are we assuming everyone knows that Org-mode is an Emacs package?

As someone who has never used Org-mode, and only very briefly dabbled in Emacs during college, I actually think that's a pretty safe assumption around these parts. No?

Even if you are uncomfortable assuming that, search results for "org-mode"/"orgmode" are unambiguous and helpful for anyone out-of-the-loop and curious, so it doesn't seem exclusionary or like a secret in-joke reserved for a secret society of HN elite.

I'm far more uncomfortable assuming everyone has the interest to follow up on every comment.

Alternatively I prefer to assume that it'll give our commentary more value if we provide some helpful context.

If our goal is to share technologies that we think are useful, we have options to make that goal more successful.

This is really cool. I end up doing a lot of this kind of stuff at work, so I plan on using the bejesus out of this.

They have a whole blog post on the 'why'

https://stackoverflow.blog/2017/11/09/why-channels/

> For example, when developers need to ask their teammates questions, they tend to default to the tools that they’re already using daily: namely, chat and email. But those tools have their own problems. Chat is ephemeral and tough to search, and email is inherently limited to the people included or copied in. Both tools put a lot of strain on the few developers at a company who know the answer to a given question, and neither method excels at storage and recall.

SmartOS has code specifically in place for using 'lx' branded zones as wrappers for docker containers (which is distinct from its support of kvm)

https://github.com/joyent/smartos-live/blob/master/src/docke...

https://www.cruwe.de/2016/01/27/using-docker-on-smartos-hype...

It's been a while since I've looked in to it, but if memory serves they are using docker filesystem snapshots without modification and running them on a thin translation layer of Linux system calls to Solaris system calls. Hard to find anything backing this up, so I could be way off the mark as to how it's implemented.

EDIT: forgot that's what 'lx' zones are: zones which allow the execution of Linux binaries

Because Firefox Focus isn't itself a browser, but rather a wrapper around Android and iOS's built in browsers. That is why the underlying engine in blink/webkit and not gecko.

I am probably drastically simplifying things but the primary components of the app are just a content blocker and a preferences page.

I would guess that's only true on IOS, because apps are forced to use the operating system's webview?

It's currently also true on Android, because Gecko doesn't yet provide a WebView style embeddable component, so Firefox Focus uses the default Android WebView instead.

There's a bug tracking work to migrate to Gecko though: https://github.com/mozilla-mobile/focus-android/issues/13 (see also the linked https://bugzilla.mozilla.org/show_bug.cgi?id=1322573)

It is also the case on Android. It's nice, because many people will want to install it alongside a full-blown browser. And it makes browser startup quite a bit quicker, making it very much effective at this one-off search use-case.

And it happens to block the vast majority of ads, so Mozilla isn't exactly making friends with webpage owners by supplying this. Had they used Gecko for this, then the percentage of people on Gecko with ads blocked would have risen and that might have resulted in webpage owners spending less time to ensure that their webpage isn't broken on Gecko, therefore effectively dragging down the situation for actual Firefox.

The example site provided ( https://greggman.github.io/doodles/html5-webcam-iframe.html ) serves an iframe from a different domain so the site settings on the visible page do not affect the actual camera permissions:

Site settings: http://imgur.com/a/JIDeD (note: camera is set to 'block', but there is still the red dot in tab indicating camera access)

Camera usage: http://imgur.com/a/3HXHo (note: different domain listed)

> As it is, in Chrome, if you let a webpage access your camera (or mic) that page gets permanent permission to access the camera whenever it wants forever, no questions asked again.

Firefox asks if you would like to remember allowing camera access (this appears to be respected when refreshing the page):

http://imgur.com/a/3lbt2

Chrome does not:

http://imgur.com/a/2aSY5

Yes, I mentioned that in the bug report.

I get the feeling camera access should always ask from an iframe period. There should be no "always allow" from iframes.

On top of that, given that many pages use 3rd party scripts from CDNs etc I feel like it's pretty dangerous to give any site permanent permission to access the camera/mic.

Digium | San Diego, CA | Front End Software Engineer | Full-Time | Onsite

Digium is looking for front end software engineers to join our San Diego team to help build realtime web applications on top of Switchvox, a turnkey phone system targeting small and medium sized businesses.

Our stack includes Linux, PostgreSQL, node.js, React, and socket.io

If you are interested, you can find the full job posting here: https://recruitingapp-7001.umantis.com/Vacancies/423/Descrip...

Or feel free to email me at bhorsley@digium.com

the http:// link you posted works fine, but if you attempt to access the link via https ( https://techblog.netflix.com/2016/05/application-data-cachin... ), I get a "Secure Connection Failed" in Firefox.

Screenshot:

http://storage8.static.itmages.com/i/16/0525/h_1464199626_32...

That said, I'm not being redirected and I don't know why gp is.

OK, I can reproduce. I'll forward, something seems wrong (obviously). Thanks for reporting this.

edit: No SSL on blogger custom domains. Sorry =/

What was the problem? I ask not to make it on my servers. Thanks.

I get the same result in Firefox and in Chrome it says This site can't be reached with a specific ERR_CONNECTION_CLOSED error. I've been wondering why this item kept getting voted up but I couldn't even access it. I'm on Time Warner Cable in southern Kentucky by the way, could this be a network issue?

Edit: I should note that I cannot access this via HTTP either as I'm getting redirected to HTTPS.

Edit 2: Correction: If I force http:// in Chrome I can access the blog entry. I tried even using Private mode in Firefox and while I specify http:// the URL gets modified to https:// and I get the insecure connection message. Above I used the word redirect but I can see no evidence of an actual redirect in the developer interface. But it's not clear to me if the Firefox development interface Network tab would indicate a redirect response.