gnur

> “We expect iPhones are similarly vulnerable, but we only tested our attack on Androids,” Peng Cheng, a doctoral student at Lancaster University told me in an email.

Well, of course not. First of all, iPhones don't have unlock patterns. Which greatly diminishes the usefulness of this approach. Also, I don't believe iOS would allow continuous use of microphone and speaker when the screen is off. And it is incredibly hard to sideload applications on unsuspecting users.

Unless you are using DC/OS enterprise, DC/OS is incredibly insecure by default. Any container running in the cluster has access to the full marathon API (which has NO auth). So any compromised container will be able to: stop and delete everything, see all environment variables set for other containers (often contain secrets for databases or other external apis) and even start arbitrary new containers on your cluster.

So think about it, any compromise in anything you run on the cluster has the potential to access all your data.

This alone should be reason enough to never use the free DC/OS, and the enterprise offering has no public pricing information.

Imagine you have some kind of SaaS that customers pay for with microtransactions.

You do some kind of work on uploaded data (let's say it's 1GB) and return data to the customer.

The classic model forces you to make all kinds of upfront costs and predictions about usage. If you decide to support 10000 concurrent users you would need to provision a 10 terabytes of storage with high speed disks and maybe 10 beefy machines. Without actually having any revenue you need to invest at least $20k.

In the serverless model, you can calculate how much it would cost.

> 1GB upload + 120 seconds of 2G serverless time + 1 GB download = $0.15

Now you charge the customer $0.25 for your work and you make a neat $0.10 profit per task. If you have a lot of customers you make more profit, if you have no customers it costs you nothing. (except your development time, but that is not unique to serverless)

If your business model works with serverless when you have a single paying customer it should work when you have a thousand paying customers.

Perhaps the tardigrades have already done that.

The Influx ecosystem actually offers https://github.com/influxdata/chronograf for graphing in stead of Grafana.

Always do at least 1 full rehearsal with a timer, preferably two full rehearsals where the first one you do keep a timer but also have a notebook (physical) present to quickly write down adjustments you want to make.

Do a live demo, people love live demo's, but be prepared for when disaster strikes (it will), if possible run your live demo on a physical device with you during the presentation.

Most places allow you to have 2 devices connected, or quickly switch the HDMI cable to the demo machine.

Do not use a linux machine, I know this sounds harsh, but with all the types of beamers/screens out there, a windows or mac machine will just have a much higher success rate. (I learnt this the hard way, in the end I could choose between mirrored 640*480 or full hd on the beamer only, which makes live demos much harder).

Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.

Use images and videos, they can tell more then a thousand words.

I often use the STAR approach to tell my story, this helps structure your talk. You don't need to follow star exactly, but if trying to explain something, it often helps to first give a bit of background why you did what you did.

Make sure you let the audience know if and when you will be answering questions, some talks really benefit from interactivity, but if you are short on time, let people know they can ask their questions later (perhaps add a slide at the end with sources and your contact information).

Also, relax, the audience has already decided they want to listen to your presentation.

Mosh only uses SSH to setup the initial connection, when the handshake between server and client has been created SSH is no longer used.

It sounds great, but I've always found the DC/OS marketplace not really flexible enough. I've looked at many services, but in most cases the requirements for running a service from the marketplace were for extremely high throughput situations. I wanted to experiment with arrongoDB but it required a total of 16GB memory (IIRC).

Practically, I think kubernetes with helm charts gets will get you at least 90% of what DC/OS offers.

Also, running Kubernetes itself is complicated enough, running it on a different scheduler will just expose you to the pains of both schedulers.

Having used both DC/OS (mesos & marathon) and kubernetes in production.

The one thing DC/OS had absolutely nailed was the web interface and bootstrap. The DC/OS interface is brilliant as it allows you to explore all the possibilities and actually have a overview of what is happening.

Also, it was a lot easier to reason about because everything is contained in a single marathon job. No need to split everything up in deployments / services / ingresses. A single JSON file is all you need for DC/OS. Less to think about.

The downside of all this is that DC/OS feels like a solution for a theoretical problem, while kubernetes is the solution to practical problems.

The free version of elasticsearch still has no real authn/authz/rbac built in.

To be fair, this is a limitation of Docker, there is nothing Traefik can do about it.

The integration of Traefik with the Docker daemon should mainly just be used while developing (imho). Once you get to acceptance / production environments, you are very unlikely to run plain docker containers, if you use kubernetes you interface Traefik with the kubernetes api itself, and the service account you create for Traefik can be (and should be) completely read only. Same for Docker Swarm, Marathon, Consul and AWS ECS.

So no, Traefik is not the big security problem you make it out to be.

Sorry to be so harsh, but Traefik is one of the most amazin pieces of software I have come across in the last years that has seriously made my life much easier.

Communicate that you are self-taught in grade school and that your work ethic primarily kicks in at home ;).

Perhaps you need to find some different words, but a strong motivation with your application helps miles in getting a job.

Kind of, except that the base ubuntu image is more like 70MB.

Do you have any sort of routine you can recommend?

Downloading it from steam takes just as mush time.

But that 50GB is probably for more then 100 hours of playtime, which amounts to a persistent 145kb/s. With some caching up front, I think this could actually work. There literally is no need to have everything on disk before starting. Maybe a few hundred megs before starting, but even that is less then a few minutes on most connections, which is a lot faster then downloading the full game before starting.

Is this the cause or the effect?

Have you taken a look at nats? (https://nats.io/)

Otherwise, the cloud native landscape has some similar projects listed in the same category as kafka: https://github.com/cncf/landscape

I actually like the GOPATH. It has forced me to order my code correctly, I now have a single ~/code directory where all my checkouts reside.

I created a small bash script (called giclo) which automatically places checkouts of git repo's in the correct ~/code/src/HOST/USER/REPO directory, super convenient and very well organized.

I used it, and I used a combination of manual and automated steps.

It wasn't worth it in the end, perhaps you could look into traefik or caddy. Both can automatically request and refresh certificates for you, caddy is good for hobby projects and is very easy to configure, traefik offers a lot of features and can be a bit harder to setup, but is truly awesome if you connect it to an orchestrator for automatic request routing.

I have minio running on a raspberry pi at home and exposed it via a port forward.

It has built in support to generate links that automatically expire.

Do you have a link for this? I have been interested in this as well, probably isn't cheap though?

Have you tried/evaluated traefik? It sounds like it could do nearly everything you just mentioned.

In my experience, this should not have to be a big issue. In the Netherlands, half of the meetups and conferences feature non Dutch speakers.

If you have knowledge about the topic you want to convey, submit a proposal (make it clear it will be English) and hope for the best.

For one thing, it isn't really a database. You can use it as one, but where elasticsearch shines is mostly write once and read often.

Correctness isn't the primary focus, so unless you are willing to lose some stuff, don't use elasticsearch as your primary database.

https://www.elastic.co/blog/found-elasticsearch-as-nosql

You can still use LE without shell access, you can manually upload the verification files and have your domain validated that way. You can even use DNS to verify the ownership of a domain.

If yaml ever gets too cranky, just use JSON in your yaml document.

Since yaml is a superset of json, any valid json is valid yaml as well. This allows you to combine the two in very convenient ways:

  ---
  test:
    obj: {"solution": ["in", "the", "list", {"everything: "is possible"}]}

I think the point that the article inadvertently makes is that any unpatched system cannot be safe.

It does have some appeal to use playbooks I have lying around anyway to build containers.

But I also notice that in an immutable world, where containers are built once and new builds are started from scratch, the main appeal of Ansible (and other configuration management tools) is in their idempotence, which has literally no value when you build everything from scratch every time.

If you provision a cluster of servers and expect that they will be updated regularly (like updating the installed version of openssl) it makes sense to use something like Ansible to make the results predictable.

But when you are building containers, a simple shell script will also have the same result every time.