DanielDent

Am I correct in assuming that the performance improvements of SSDs are worthless for your use case?

It seems like the workload of Backblaze (like many "big data" workloads) is such that the extra IOPS don't actually help.

With thousands of drive spindles, and a very small portion of the data on on the spindles being needed at any given moment, I don't imagine you are actually limited by the performance of spinning rust.

Actually they aren't only browser based. You can run native code:

Behold:

https://www.chromium.org/nativeclient/pnacl/introduction-to-...

It's an amazing & beautiful feat of engineering. I'm unclear about it's feature - I suspect webassembly may become a standards-based equivalent that makes NaCL and PNaCL unnecessary.

Bitbucket, which they also support, shows me the key they added to my repo.

Using the key they placed on my Bitbucket repo worked on one of my Github repos.

Once upon a time I did some work at a software firm which serviced financial institutions, including many very recognizable names.

I came into work one day and a colleague had a piece of paper on his desk requesting that we not touch his machine.

A macro was running which was switching between two open programs, highlighting fields, and copy and pasting data.

I'm still not sure if I should be alarmed or in awe. It was probably the most sensible option of the available options...

It's not documented anywhere, so it's possible they use different keys for different users, but I was able to figure out they use this key for my account:

    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8cBZzV5gblDfbi41AxXC3fmfP8w1okfdNn9b6uXaj7i03NwhJ0n4Eg8Z+zgAtyrIa2bw9tzF8fyeYsnRbK5Paj059dn+XiXp3HOgcvHO9jy9C1+nomkRCM55fkMSGyiSByh2KSOiqqAusrTV9joig/Re30gYpxm8iCs20gbD717lZTT0A3dnrv7IQ86nbn9+5h+yMcok/AWEWS6Xq1NJGG5vav+vh+Nhlteo72qj77B/DFK1noUxcTgcy27xZOp1wrr7a6PaBu6wEMgKd2Oe9wQtzycaOYTAywHqtXnOE/w7FvhJen20GqtL9k4Zr94hxUNG7LJoiO6gNzo/0q24t git@theo.gitlab.com

Large cloud providers may have poor IPv6 support, but they do have some support.

For instance, do a DNS lookup on netflix.com. You'll find IPv6 records pointing to Amazon AWS IP space.

The few times I've been asked for cash because the credit card machine is 'broken', I've offered (a) they can use the swipe machine and run the card later, or (b) they'll need to come back when it's fixed and I'll gladly pay them at that time.

They aren't always happy about it, but somehow they typically fix their machine. Within seconds.

I think the reason SMTP is hard to get right is not because of the many RFCs. The reason is that it's not documented.

Operational experience at scale is needed to know how to write an effective SMTP implementation, and that experience is half-documented by many people in many different information silos.

But... I'd also say it's an extremely forgiving protocol. In fact, it's the fact that it's so forgiving which makes operational experience required to implement it. A "correct" SMTP implementation has a lot of latitude in the choices it makes - and it's that latitude which makes life difficult.

Using Amazon as a benchmark for bandwidth prices is not a good starting point.

Amazon charges are $x.xx/GB. Providers which compete on bandwidth costs charge $x.xx/TB.

300x cheaper than Amazon is a little difficult, but 50-100x cheaper is a price at which bandwidth can be profitably sold.

The problem with your narrative is that:

(1) Traditional taxi companies don't usually have employees. They mostly have independent contractors - just like Uber

(2) In many areas, taxi drivers actually pay the taxi company for the right to use the taxi. They do so because the taxi company owns or rents a government license required to operate a taxi.

If the exercise is to compare being a taxi driver for Uber or a taxi driver for a traditional taxi company, in many areas, there is no case to be made that Uber offers worse working conditions.

Does this mean we are now at a point where LXD/LXC & docker will play nicely with each other?

While I agree with you, I think we could get closer to "production" than is common right now.

In an AWS environment, imagine a setup where all that differs is the API keys used (the API keys of the production vs test environment). What gets tricky is dealing with external dependencies, user data, and simulating traffic.

For an example more relevant to today's issue: imagine a second simulated "internet" in a globally distributed lab environment. With BGP configs, fake external BGP sessions, etc, servers receiving production traffic, etc.

I get that it's a lot of work to setup and would require ongoing work to maintain - and that it's hard/impossible to have it correctly simulate the many nuances of real world traffic - and yet I also think in many cases it would be sufficient to prevent issues from making it into production.

Any sufficiently large system quickly reaches a point where a human has difficulty tracking what the system should look like.

Google has at least tens of data center locations, each of which will have multiple physical failure domains.

There are also many discontiguous routes being announced at all of their network PoPs. They have substantially more PoPs than data centers.

It very quickly gets too much to reasonably expect people to be able to keep track of what the system should look like, let alone grasping what it does look like.

My post yesterday seems even more relevant today: https://news.ycombinator.com/item?id=11477552

It's a shame it's not easier or more common for people to create clones of (most|all) of their infrastructure for testing purposes.

Something like half of outages are caused by configuration oopsies.

If you accept that configuration is code, then you also come to the following disturbing conclusion: the usual test environment for critical network-related code in most environments is the production environment.

Widearea/public cloud & non-VPC use cases are my use cases.

I really wish this weren't true, but your solution is not pretty good yet. For now, if you need encryption, it's useless.

Machines spend their life handling packet overhead. Application performance suffers horrendously, and the scalability of the application goes from excellent to terrible.

Weave looks really good if you give it easy tests involving big packets. But if you give it a workload involving many small packets (which in today's microservices architectures is not exactly uncommon), it stops working.

RFC1883 IPv6 was written in 1995.

I have services where >30% of my users access the service over IPv6.

It's terribly slow unless you don't care about encryption: https://github.com/weaveworks/weave/issues/1925

The per-packet processing overhead is a real and unresolved problem.

I'm using Rancher's networking now instead. It uses ipsec between hosts, so everything gets handled by code paths which have been optimized in the kernel, and performance is good (especially if you have a not-ancient CPU and have the AES-NI instruction - then wirespeed gigabit works with acceptable overhead).

I like Weave's decentralized architecture and wish it were realistic to use it.

If they are going to stick with a user-space solution they probably need to use DPDK or one of the other high-performance software defined networking toolkits, which tend to process packets using a SIMD approach.

You get an AS number, and announce your own IP space. DNS failover only sort-of works.

Or your subscribe to a "GSLB" service where they do this for you for a significant fee. Or you use a "man-in-the-middle as a service" system like Cloudflare, who do this at an extremely reasonable and/or free cost.

Of course, you still have to deal with the risk of route leaks, BGP route flapping/dampening, and other things which can take your IP addresses offline despite the fact you are multihoming with different carriers in different locations.

So perhaps you setup IP addresses on different ASNs and use both DNS & IP based failover.

But then you find a bug somewhere in your software stack which makes all of this redundancy completely ineffective. So you just take your ball, go home and cry.

Unfortunately I think you have it backwards.

Malware ads are being displayed because they are winning the auctions. That's because - on a CPM basis - malware authors are probably the ones who will always be able to pay the most. A successfully infected machine is worth a good chunk of change.

Ad networks are uniquely suited to malware delivery. Have an exploit which only works for OS X users? Don't bid on the windows users.

WhoisGuard is Namecheap's privacy protection service. There is nothing unusual or untoward about not wanting your contact information being used for spear phishing, spam, ... I'm not convinced contact information should be required when registering a domain. Why should it matter who owns the domain?

A docker container can run in host networking mode.

You could also disable the DNAT and route IPs to your containers. Docker uses network namespaces to create a bridge to the actual ethernet card - the DNAT part of things is only one possible configuration.

IPv6 makes it easier to have routable addresses.

The right choice is going to depend on the available infrastructure, performance requirements, workload profile, ...

But really, in most environments, connection tracking simply isn't the bottleneck. Where it is, configure your systems not to use it.

Others have already mentioned how Tor bandwidth/latency issues could make things substantially worse for 'real' Tor users outside of their simulation.

But the bigger issue I would wonder about is Google's reputation systems. Google does not treat all CAPTCHA requests equally.

An office full of CloudFlare employees peaceably going about their daily browsing is going to get a much easier CAPTCHA situation than a Tor IP containing a mix of automated nefarious activity and individuals peaceably browsing from infomatically repressed countries.

My testing has shown they are accessible over the internet :(.

They are not marked as 'preferred' and won't be used by default. But they are still available for use if someone goes out of their way to do so.

I'm not sure I understand what your use case is for pushing static routes & would be interested to understand what you mean.

I've been trying a few different approaches to routing. Putting link-local addresses in routing tables has worked well in some deployments.

Debian & OS X use MAC based addresses in addition to their privacy addresses. https://www.danieldent.com/blog/remote-ipv6-device-fingerpri...

People are going to have to wrap their head around the brave new v6 world.

I get "logged in from a new IP address!" alerts with a service I use almost every time I log in, even though my IPv6 prefix hasn't changed. Deciding it's a completely new IP just because something changed in the last 64 bits is probably a bad idea in a v6 world.

Devices being multi-homed is intended to be standard practice.

My iPhone regularly has multiple IPv6 addresses, with different reachability characteristics for different addresses. There's an address used by my carrier for voice, there are addresses I locally administer, there are addresses from a stable prefix I use, addresses from dynamic prefixes provided by my upstreams, ...

The v6 world is a world where many devices have many addresses and addresses do not all have the same scope.

Application developers are going to need to get used to this new normal.

An application I manage has ~40% of users accessing it over IPv6, most of which would have a degraded experience if we didn't offer v6 connectivity.

IPv6 is here, it's here to stay, and applications are going to need to understand the new world they live in.

NAT can actually still be pretty useful in IPv6. But in IPv6 it's also realistic to do prefix translation, so that while there is NAT, it doesn't foreclose on the possibility of end-to-end communication.

Multihoming, site renumbering, and a few other issues are areas where work still needs to be done. Prefix translation is a current workable answer to some of those problems.

"100.64.0.0/24" - I'm pretty sure you meant /16 (or even /10). Unless you only plan on having ~250 customers.

Interesting choice of IP range. It's reserved for carrier NAT. While I can see benefits to the choice, it could also make the service unusable for some of the customers that would most benefit from your service.

[Wikipedia]

In programming languages, closures (also lexical closures or function closures) are a technique for implementing lexically scoped name binding in languages with first-class functions. Operationally, a closure is a record storing a function[a] together with an environment:[1] a mapping associating each free variable of the function (variables that are used locally, but defined in an enclosing scope) with the value or storage location to which the name was bound when the closure was created.[b] A closure—unlike a plain function—allows the function to access those captured variables through the closure's reference to them, even when the function is invoked outside their scope.

I'm disturbed by the amount of CSS that was used to try to make the page look like it hadn't been styled.

Font choice: "propagandaregular". Are we being trolled?

The ring buffer approach reminds me of the architecture used by the LMAX Disruptor.