What you will do
Here are the steps you will go through:
- Spawn a cloud instance which will host our demo website.
- Do some basic hardening of our server and set up Nginx.
- Install a brand new Let’s encrypt certificate and set up its automatic renewal
- Harden the Nginx configuration
- Harden the Security Headers
- Get that shiny A+ security rating you are looking for
This tutorial will use Exoscale as cloud provider since they offer integrated firewall and DNS management. On top of that Exoscale has a strong focus on data safety / privacy and security. Of course you can follow along using any other cloud or traditional hosting service.
The linux-based open-source mobile operating system Android is not only the most popular mobile operating system in the world, it’s also on the way to become a proprietary operating system. How is that?
While the core operating system is still released as part of the Android Open Source Project, the majority of core apps is not. It even got worse: More and more libraries and APIs are only available on phones that run various Google apps pre-installed, effectively locking third-party apps to the Google ecosystem. For these reasons Android is called a “look but don’t touch” kind of open.
By now, several popular open-source applications like the secure messenger Signal already require some of Google’s proprietary libraries to be installed. Increasing demand in the free software community in addition to severe problems in Google’s proprietary software discovered by the Android modding community led to the development of a free software clone of Google’s proprietary core libraries and applications – the microG Project was born.
Although most microG components are far from complete, users are amazed by the results. Free software users got extended application support, privacy-caring users can reduce or monitor data that is sent to Google and especially older phones can expect quiet some battery life improvements. microG is not only used on real devices, but also replaced Google tools in some test emulators and is even used in virtual mobile infrastructure.
In 2007, Ulrich Drepper wrote a “What every programmer should know about memory”. Yes, it’s a wee long-winded, but it’s worth its salt. Many years and “every programmer should know about” articles later, the concept of virtual memory is still elusive to many, as if it was a kind of magic. Awww, I couldn’t resist the reference. Even the validity of the original article was questioned many years later. What gives?
“North bridge? What is this crap? That ain’t street-fighting.”
I’ll try to convey the practical side of things (i.e. what can you do) from “getting your fundamentals on a lock”, to more fun stuff. Think of it as a glue between the original article, and the things that you use every day. The examples are going to be C99 on Linux, but a lot of topics are universal. EDIT: I don’t have much knowledge about Windows, but I’d be thrilled to link an article which explains it. I tried my best to mention which functions are platform-specific, but again I’m only a human. If you find a discrepancy, please let me know.
Without further ado, grab a cup of coffee and let’s get to it.
In this article, we’ll show how to use virtual environments to create and manage separate environments for your Python projects, each using different versions of Python for execution, as well as how Python dependencies are stored and resolved.
Fast forward another couple months and I’m at my current job as a backend developer for Digg. When I joined, back in April of 2015, the stack at Digg was primarily Python with the exception of two services written in, wait for it, Node. I was even more thrilled to be assigned the task of reworking one of the services which had been causing issues in our pipeline.
Our troublesome Node service had a fairly straightforward purpose. Digg uses Amazon S3 for storage which is peachy, except S3 has no support for batch GET operations. Rather than putting all the onus on our Python web server to request up to 100+ keys at a time from S3, the decision was made to take advantage of Node’s easy async code patterns and great concurrency handling. And so Octo, the S3 content fetching service, was born.
Node Octo performed well except for when it didn’t. Once a day it needed to handle a traffic spike where the requests per minute jump from 50 to 200+. Also keep in mind that for each request, Octo typically fetches somewhere between 10–100 keys from S3. That’s potentially 20,000 S3 GETs a minute. The logs showed that our service slowed down substantially during these spikes, but the trouble was it didn’t always recover. As such, we were stuck bouncing our EC2 instances every couple weeks after Octo would seize up and fall flat on its face.
pytrader is a cryptocurrency trading robot that uses machine learning to predict price movements at confidence intervals, and sometimes execute trades. It is programmed to work on the poloniex.com cryptocurrency platform.
I (@owocki) built this as a side project in January / February 2016, as a practical means of getting some experience with machine learning, quantitative finance, and of course hopefully making some profit
3/26/2016 – My test portfolio was initialized with a 1 BTC deposit, and after 2 months and 23,413 trades, exited with 0.955 BTC. The system paid 2.486 BTC in fees to poloniex. CALL TO ACTION — Get this trader to profitability. A strategy is being fleshed out here.
libnghttp2_asio is C++ library built on top of libnghttp2 and provides high level abstraction API to build HTTP/2 applications. It depends on Boost::ASIO library and OpenSSL. Currently libnghttp2_asio provides server and client side API.
libnghttp2_asio is not built by default. Use --enable-asio-lib configure flag to build libnghttp2_asio. The required Boost libraries are:
In previous discussions of Bayesian Inference we introduced Bayesian Statistics and considered how to infer a binomial proportion using the concept of conjugate priors. We discussed the fact that not all models can make use of conjugate priors and thus calculation of the posterior distribution would need to be approximated numerically.
In this article we introduce the main family of algorithms, known collectively as Markov Chain Monte Carlo (MCMC), that allow us to approximate the posterior distribution as calculated by Bayes’ Theorem. In particular, we consider the Metropolis Algorithm, which is easily stated and relatively straightforward to understand. It serves as a useful starting point when learning about MCMC before delving into more sophisticated algorithms such as Metropolis-Hastings, Gibbs Samplers and Hamiltonian Monte Carlo.
Once we have described how MCMC works, we will carry it out using the open-sourcePyMC3 library, which takes care of many of the underlying implementation details, allowing us to concentrate on Bayesian modelling.
How it works: Because you can never observe a scenario in which
fail has been called (since it destroys the universe), you will necessarily observe a “fortuitous” timeline in which the values returned by
choice cause your program to complete without ever calling
fail. Be careful to ensure that such a timeline exists!
Do not run a program that calls fail() unconditionally or in every timeline. Such a program destroys every universe in which it runs correctly, so the only observable outcome is one in which an extremely unlikely (and potentially dangerous) event prevents it from completing.
When there are multiple possible (non-
failing) executions of a quantum program, we consistently end up observing the lexicographically smallest one with respect to the iteration order of sequences passed to
choice. This phenomenon remains unexplained.