yourcelf

It may be a bit more zoomed out than what you're looking for if you're specifically looking at philosophical treatments of the practice of engineering, but Andrew Feenberg's "Questioning Technology" is excellent introduction to the philosophy of technology, particularly exploring the interplay between technological constraint and political/economic/social drivers of its development.

"Philosophy of Technology" in general is a pretty rich field with a long history, and you might find more references in it than in engineering specifically.

`django-environ` makes a fairly simple effort[1] to strip starting/ending quotes off of literals. This will set the value of MY_VAR to the string `foo` (with doublequotes removed) in django-environ:

   MY_VAR="foo"

Docker does not do any quote parsing. For this same env file, it will set the value of the variable to `"foo"` (retaining the doublequotes in the value).

Bash, of course, requires quotes if the variable contains any special bash characters (for example, literal JSON with curly brackets), but its quote handling is much more complex. django-environ doesn't interpret bash code; it just does simple quote chomping.

There's no reliable .env syntax you can use that works in all 3 of django-environ, Docker, and bash; and any variable that should start and end with quotes that are not stripped off can't be expressed in a way that both Docker and django-environ will read in the same way.

This may seem like a nit-picking edge case, but it's indicative of the design philosophy in django-environ of trying to be "helpful", but in ways which lead to subtle confusion. The way it guesses the path to your `.env` file is another example.

[1] https://github.com/joke2k/django-environ/blob/main/environ/e...

While we started off using `django-environ` to help manage environment-based/12-factor settings, we've moved away from it in favor of django-classy-settings.

The biggest knock against django-environ is that it does not treat the `.env` syntax the same as Docker or bash -- meaning that the same environment file can't be reliably used to provide variables for both the container and Django.

django-classy-settings has been a joy to use, and its code is really simple and readable (~150 lines).

[0] https://github.com/funkybob/django-classy-settings/

Radio Gaga: A Mixtape for the End of Humanity, by Stefani Bulsara.

An off-kilter, hilarious, inventive, and cutting apocalyptic sci fi novel about pop music. Writing style is like Douglas Adams meets Tom Robbins, through the lens of Top 40 radio and tabloids.

https://www.indiebound.org/book/9781733712569

A problem we've run into with Radar is that it only kicks in when you attempt to create a charge, and not when you attach a card to a customer.

This means that if your business model involves "try before you buy" or usage-based billing, you'd better be sure to make an initial charge, otherwise the customer might incur costs before Radar decides to block the charges.

Even if you do require an initial charge, if you allow customers to change their credit card between recurring charges, the new card could be extra risky and "fly under the Radar" until the first charge attempt.

Are there any plans to offer fraud risk and blocking when attaching a card to a customer, or will still be limited to just blocking charges? With Stripe's new emphasis on recurring billing, it seems like this would be important.

We currently see Radar as a liability for us. It might block the occasional fraud and avoid a chargeback, but it also allows customers to incur costs with dodgy cards before we know they're dodgy, and then blocks charges outright before we know.

Status in Ubuntu: https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2...

Indeed -- the demographics of Montana in particular are overwhelmingly white[1]. As of the 2010 census, 89.4% white, 6.3% native (many of whom live in one of the seven reservations Montana has, rather than the "star" towns of Billings, Bozeman, and Missoula), and less than a percent each for any other races. The state also has only just over a million people total, so there are about 4 times as many white people in New York City as there are in the whole state of Montana.

This isn't to excuse the white-washy-ness of the video (e.g. lots of cowboys, no Indians), but just to say that the problem is at least a couple of levels out from just this video.

[1] https://en.wikipedia.org/wiki/Montana#Demographics

The TextSecure protocol is now named the "Signal Protocol"; it's developed by Open Whisper Systems. It is the protocol used by the Signal app on Android and iPhone, and as of this week, also used by WhatsApp.

Here is an older post where the authors of the protocol explain why not OTR: https://whispersystems.org/blog/advanced-ratcheting/

The main takeaway: text messaging, unlike traditional instant messaging, is primarily asynchronous with long-lived sessions, where traditional instant messaging is primarily synchronous with short-lived sessions.

See also "Plotto: The Master Book of All Plots."

https://www.goodreads.com/book/show/11454870-plotto

http://www.npr.org/2012/02/19/146941343/plotto-an-algebra-bo...

It's even worse if the sound is going through a digital (VOIP / cell phone) system. Most modern codecs for voice are using some form of Linear Predictive Coding[1] (e.g. ACELPC) which is basically modeling sound as a resonator at the bottom of a tube with a filter bank (sortof like your voice box). With voice, this is a reasonably good approximation, and the codecs are aggressively tuned to be efficient at that. But if full-band music gets piped through it will sound roughly like that music is being produced by a flapping plosive at the bottom of a long tube.

[1] https://en.wikipedia.org/wiki/Linear_predictive_coding

If you'd like MIT students who were impacted by the administration's callous lack of support, consider:

- the MBTA "hackers", 2008: http://www.openmediaboston.org/content/mbta-suit-against-mit...

- Star Simpson, 2007: http://www.boston.com/news/globe/city_region/breaking_news/2...

- Ryan McKinley's "Government Information Awareness", 2003: https://en.wikipedia.org/wiki/Government_Information_Awarene...

- Andrew "Bunnie" Huang, 2002, XBox hacker: https://en.wikipedia.org/wiki/Andrew_Huang

- Ladyada, 2002: http://www.ladyada.net/pub/research.html

- David LaMacchia, 1994: http://cd.textfiles.com/group42/WAREZ/LAMACCHI.HTM

And these are only a few cases that made headlines; there are many additional controversies handled more quietly. The point remains that the MIT General Counsel's office exists to protect the institute, not the students, even while MIT's culture rewards innovative, boundary-pushing work.

The point at issue here is that MIT needs a legal support structure for such students commensurate with its encouragement of the work.

Would love to see this protocol for email as well.

Moxie Marlinspike gave a fantastic talk on this subject in 2010, even down to the government mandated tracking device vs mobile phone: https://www.youtube.com/watch?v=eG0KrT6pBPk

Here's a set of default templates I wrote. I respect the reasoning for not providing them, but implementing 15 templates to get started out of the box is a bit onerous. https://github.com/yourcelf/django-registration-defaults

Emphatically: yes. Those who collect stats on them find that they contribute a substantial portion of shares.[1] People rant against them often, probably because they wish they weren't effective, and they might not personally click them. But others do.

[1] http://www.luigimontanez.com/2012/actually-social-media-butt...

Got it, thanks. More detail at [1] mentioned by gingerline above: "the secure flag does not prevent a cookie from being overwritten. In fact, a HTTP site can overwrite a cookie with a secure flag, as long as the domain names are related appropriately. The secure flag provides confidentiality protection but not integrity protection."

[1] http://security.stackexchange.com/questions/12412/what-cooki...

Github only sets their cookie for "github.com". What I'm suggesting is that they set multiple http-only cookies: one for "github.com", one for ".github.com", another for every subdomain you access -- "pages.github.com", etc. If there's already an http-only _gh_sess cookie for every subdomain I can put scripts on, I won't be able to shadow it with my own _gh_sess cookie.

Wouldn't a solution be for the server to set its session cookie for every subdomain, as HTTP-only? For example, set "_gh_sess" for every requesting domain, whether www.github.com, github.com, something.github.com; and ".github.com" as well. If you hit them all, you prevent js from shadowing them.

This idea goes back further than you might think. The "Stereoscopic Workspace", from the Architecture Machine group at MIT in 1983, was a prototype of this idea, surprisingly close to this implementation 30 years later.

http://media.mit.edu/speech/videos/?video=Stereoscopic%20Wor...

http://media.mit.edu/speech/papers/1983/schmandt_SIGGRAPH83_...

Indeed. A good way to increase diversity in hiring is to set a rule: your hiring process isn't done until you've received a minimum number of applications from various demographics that are underrepresented.

You still pick the best applicant from all submissions, but it forces you to make sure that news of your position spreads into more than just the usual communities.

See http://freedomdefined.org/Definition for a view (not RMS's) which extends the spirit of the Free Software definition to "Cultural Works", including art, music, etc.

Creative Commons has adopted the language of "Free Culture Approved" for licenses which meet this definition. Not all CC licenses do (in particular, non-commercial or no derivatives clauses are incompatible).

I think it's similar to http://isitchristmas.com/ . It's a simple answer that's always the same, to drive the point home: you are always the one responsible for your uptime, no matter whether you choose dedicated hosting, the cloud, your own closet, etc. You can't outsource responsibility.