spectre256

It's definitely worth repeating the warning that, while very useful, Strict-Transport-Security should be deployed with special care!

While the author's example of `max-age=3600` means there's only an hour of potential problems, enabling Strict-Transport-Security has the potential to prevent people from accessing your site if for whatever reason you are no longer able to serve HTTPS traffic.

Considering another common setting is to enable HSTS for a year, its worth enabling only deliberately and with some thought.

Yeah, this definitely is a way to break the filter bubble.

But thinking about it a bit more, it might be one of the worst ways to do so.

For example, assuming roughly that both favorites and retweets represent general agreement, using those mechanisms to surface new tweets to people makes sense. If someone you follow (and presumably respect) quote retweets someone you don't follow with "Yes this!" or something similar, then you're already primed to agree with the person you follow.

But, often at least, replying and not faving/retweeting could very well bais for DISagreement. Now instead you're going to see someone you follow and respect arguing about something, and you're primed to agree with them, and potentially pile on to the original tweet author even though you might not have cared about the topic a minute ago.

Twitter ALREADY has a way to signal that you want all your followers to see a tweet you saw: retweet. And even showing your followers things you favorited at least means they'll see things you probably like. But it seems there's at least a reasonable argument that showing your replies to your followers is setting up a situation where pile-ons to the original tweet are likely.

The missing piece which the Twitter thread author only touched on is that how a tweet is received by a reader depends a lot on whether or not they come from similar communities and have similar context to the author. By surfacing tweets to people that the author doesn't know at all, it's likely the responses will be more negative in general.

Anyone with a large twitter following knows roughly what the makeup of their follower base is, and they compose tweets accordingly. While always necessary to some extent, it's usually hard to contextualize every single tweet as if it could be read by anyone, so it often isn't done.

As a silly contrived example, lets say I am a software developer that focuses on operating system performance and I tweet something like "I'm working on an algorithm to make killing children an order of magnitude more efficient". (note to real twitter users: never tweet that)

My followers know I'm talking about killing child _processes_ on a computer. So they reply things like "oh, that would be great, it would make this one shell script I have a lot faster to execute" or maybe even "personally I'd rather you encouraged users to use threads rather than forking lots of processes". There might be a heated discussion, but it will be with a HUGE shared context of information.

Now the Twitter algorithm picks it up, and the tweet gets seen by lots of people who don't know anything at all about operating systems. They are, understandably, completely appalled. They start responding with anger. Threats, abuse, etc.

So, Twitter changing the dynamic from "your tweets will primarily be seen by your followers" to "your tweets will frequently be seen by your followers followers" can actually have a big impact on the platform. It will at minimum take some adjustment. Operating with the assumption of one dynamic when there is in fact the other will be...painful.

Its a really nice idea, but I wonder if it would work in practice:

1. Would a significant amount of real humans who actually cared about the content cast a vote (up or down)?

2. Would it be even remotely possible to protect against fraudulent voting at Google scale? (remember they can't even prevent fake business listings on Google Maps, which is at least theoretically closer to verifiable from, for example, business records)

I'm a pilot, and absolutely this is a crucial difference.

It also reminds me of a time years ago when a team I was on had to extend a Memcache client library, as it couldn't differentiate between the following two conditions:

- "I tried to retrieve a key from cache but was unsuccessful (due to connection error, etc)"

- "I tried to retrieve a key from cache but determined conclusively that key does not exist in the cache"

If it was important for a caching layer on our silly social game, the same thing is clearly important in aviation.

For those who aren't familiar with her, Stephanie has been an extremely helpful and resourceful voice on Twitter (and clearly, her blog) on a whole range of topics:

- Founding and running a small company

- Working in/with/around the video game industry (good and bad)

- Health, work life balance

- Identifying and reducing bias in all sorts of situations (work, social, online, etc)

- Tasty, healthy food to cook with vegetables

She's well worth a follow: https://twitter.com/sehurlburt

Yeah, with all the research about how well correlated legitimate academic achievement is with family wealth, what does it say about you when you have to pay extra for one of these "consultants"?

It's important to note that this set of rules is for use with a small (<10000), known, possibly hand crafted set of results.

Exact matches always come first.

One place this very first rule doesn't work is autocomplete for geocoding.

If you are typing "London":

- There is a village called Lon, Pakistan [1]

- There is also a village called Lond, Pakistan [2]

- There are numerous places called Londo all over the world [3]

So its necessary to determine that some places are more likely to be typed than others (population is a commonly available number that can help, but doesn't always work), or autocomplete becomes useless.

[1]https://spelunker.whosonfirst.org/id/1209616309/

[2]http://www.geonames.org/1370290/lond.html

[3]http://www.geonames.org/advanced-search.html?q=londo&country...

I'm exactly the same way. If I can get a few things checked off my todo list early, I'm nearly guaranteed to at least feel like I had a good day.

Maybe, but that actually provides at least a little lasting value.

The ultimate example of toil, which I'm sure Google has automated away at this point, is truncating old log files that would eventually take up all remaining disk space. Simply truncating the file does not solve the inherent problem, but buys you more time before you'll face the exact same situation again.

The Google SRE book has an excellent description of toil and, unexpectedly, discusses that some amount of toil is beneficial.

In short, the authors of that section claim that it's not really possible for the SREs at Google to spend all their time solving novel problems through automation.

This makes sense: constantly solving new problems is hard. It takes lots of time, mental energy, and the outcome is inherently uncertain.

Google found that some amount of toil (roughly defined as repetitive tasks that are not particularly challenging and do not solve long term problems) is essential for the health of their engineers. Toil is boring yes, but can be relaxing, and as work that is inherently easier to accomplish, can help keep confidence that working on solving unknown problems can deplete.

I would have expected that Google would have absolutely minimal toil, given that they are leaders in the automation space, but if they've found that some amount of easier work is necessary, then it's probably true for anyone.

It really makes sense that something like this would be the case.

All the experts say "oh, Ruby uses lots of memory for [reason] and it can't really be fixed", so no one even tries.

Until someone comes along who is either motivated, smart, or ignorant(!) enough to try to fix it anyway, and finds that the commonly accepted answer was wrong.

This happens all the time, especially in science. Trust, but verify, I suppose.

Years ago I worked at a large online casual gaming company who's name ended in -ynga. Our web tier was split into two: one for serving static content required to load the HTML, Flash app, assets, etc. The other was for actual communication regarding actions taken in game.

Whenever we had any sort of issue we could generally get a good idea of what was happening by looking at changes in traffic in those two web tiers.

If people couldn't play for most reasons, game action traffic would drop to near zero, but the static asset tier traffic would usually at least triple.

So yeah, there are a lot of F5 buttons being hit out there when pages don't load.

Exactly! VC funding has its place, but it also greatly restricts the types of outcomes that are favorable.

I mean, in our case, we're building a geocoder. We'd have to raise, no exaggeration, tens of billions to build a moat considering the current market leader is Google. There's no way to guarantee that outcome.

On the other hand, there is _so_ much room left after Google for other companies if they don't have to get massive. There's room for us, and at least a dozen other companies I know of that have their own take on geocoding that their own customers appreciate.

Honestly, if the open source project we maintain ever becomes popular enough that a big company like Amazon puts effort into supplanting us, great.

We'll be known as the team that created and grew the project, and we'll have a guaranteed job at Amazon and a bunch of other places doing something we have unique experience with.

My goal isn't to leverage open-source software into enough of a moat to build a billion dollar company. If it was, then I might be unhappy if Amazon broke that moat.

I'm totally happy building a sustainable small business. Maybe even one that won't last forever. Our team is small, our costs are low, and we are comfortable. We are growing, sustainably, and providing real value to our customers in the process (or they wouldn't pay us the rates we require to stay in business).

I run a company that offers consulting and hosted services around a 100% open core (https://geocode.earth, shameless plug).

As someone who has a very strong desire to continue to be able to make a living while making open source software, I've been thinking long and hard about all the possible paths to take while maintaining open-source software as a job that pays the bills enough to run at least a small business.

Some paths and possible outcomes are:

- Open-core: Make most code pure open source, and then save some good stuff for pure proprietary. The lines are not _too_ blurred here, but this can get annoying. (Elastic's X-Pack was _super_ annoying to deal with back in the 2.x days). Risks: you have to balance crippling the core versus building compelling proprietary features. You have to add additional complexity into both codebases to deal with a clean delineation. Amazon (or other bigco) can re-implement open-source replacements for your proprietary parts.

- Source-available: This in my mind includes any of the recent Redis Labs style licenses. Pros: more convenient from a setup perspective. Cons: Incredible legal risk for your users (compliance is harder). Uncertainty as all these licensees are new and possibly one-offs. Currently, there is a lack of goodwill around these licenses. Amazon can re-implement your entire interface (like with Mongo).

- All open source: Simple, clean, but Amazon can just take all your code and replace you, right?

It's possible to assume that all scenarios end poorly, but I really don't think so.

Take any famous chef. They probably have published a cookbook with recipes for many, if not all of their most popular dishes. People still eat at their restaurants for at least the following reasons:

- They want to experience the dish from the actual chef's establishment. Whether it's to be sure they're getting the real deal or simply for the image aspects of the experience, it's still worth it.

- They know that the chef is always experimenting and pushing new things that aren't _yet_ in a cookbook, and they want to try it.

Bringing this back to software, I am confident Elastic still has a reputation of being able to build a better Elasticsearch hosted service than AWS (in my experience, Elastic's is far superior). I also am confident that Elastic will continue to innovate using their proven experience building search products in the future, and that's a good reason to use their products or software over AWS.

I believe that if you want to make money in open source you should do it by having valuable experience with some particular open source software that others are willing to pay for, not by building legal barriers to others doing the same thing. That's what I plan to do for my business and I believe Elastic can and will do it too.

My hope is that in a few years after all these "clever" attempts to build moats around open source have proven futile, people will go back to good old-fashioned experience leading the way. But maybe I shouldn't hold my breath.

The two most insidious things I've found in AWS billing:

- If you want the AWS dashboard metrics to have 1 minute instead of 5 minute granularity, that's $2.10 per instance per month. 5 minutes is pretty useless, so either you set up other monitoring or you pay a tax on the number of instances you have.

- If you use AMIs (which you probably should) to launch EC2 instances with all your software baked in already, you will probably end up with dozens or hundreds of old, unused AMIs. Furthermore each of these AMIs is linked to a snapshot, which is stored on S3. S3 pricing is very cheap but it's a significant amount of work to determine which AMIs are no longer in use and to delete both the AMI and the corresponding snapshot. Every 100 AMIs you have at the standard 8GB root volume size costs you $18/month.

Right. It would have been be clearer if I sad people pay RedHat for the promise that they quickly make a patch for any issue available, and that they know how to identify which patches are relevant for any individual customer.

What's the joke where someone fixes some machine and charges $1000? Their cost breakdown was:

turning a knob: $1

knowing which knob to turn: $999

The same thing happened to me. I recently acquired a pair of Bluetooth headphones, and even though it seems like a pair of wired earbuds or headphones would be about the same, it's not at all.

I listen to podcasts while doing all sorts of things now.

RedHat is (was?) sortof an example, but their product wasn't the open source software per-se, it was the guarantees their consulting and support offers.

RedHat makes, for example, patches for kernel vulnerabilities, but they actually give that away for free. What they sell is a promise that when there's a new vulnerability, you can get a patch from them quickly.

They also spread this service across MANY different open source packages. Like you said, a company that just offered services around a smaller package would have to run a lot more lean and would probably be a risky venture.

That's how I interpret it as well. I also think interesting articles on a topic jog people's memory and cause them to re-submit interesting articles from the past on that topic.

Whether or not Mapbox collects more data is an interesting question. My guess would be they do, by a lot.

If you look at their website, Mapbox is all about "live" location data, insights, etc. The days of them just being a provider of nice services built around (mostly) open data are probably over. They have a huge userbase and can leverage all that data to do powerful things.

I'm not a VC, but your last point is worth emphasizing. It used to be that if you wanted money for your company your options were basically:

- go to your bank for a loan for a little money you have to pay back fairly soon

- go to Sand Hill Road and get investment with the condition that you have to shoot for a huge outcome or die trying

There's a _lot_ more in the middle now, and that's really cool.

Well, we are bootstrapping a SaaS as well, which is much more Stripe-friendly (we take payments via Stripe). Either that, or I got lucky and they didn't notice.

If you are doing purely consulting you probably don't need Stripe Atlas, as the Stripe integration and AWS credits likely won't help you. But if you are doing consulting, I also recommend turning your consulting expertise into a SaaS somehow :)

My experience is from early 2013. I guess that is 6 years ago now :) Glad to hear things have improved a bit.

Actually not IO performance, but mostly CPU. Last time I tested (which admittedly was about a year ago), an AWS ES cluster was about 20% slower than a self-made cluster with the same instance types. Given that AWS ES clusters still cannot use C5 instances, which offer FAR better cost/$, the performance disparity today might be even larger.

I can also launch an Elasticsearch cluster myself in about 2 minutes via terraform, so 20 minutes is not super impressive.

That said I recognize Elasticsearch is actually quite a finicky beast to set up, and my setup only has to deal with the needs I have, and probably would be set up horribly for certain other people. I can see how a hosted system that has to deal with all the weird edge-cases of a few thousand customers would take longer to set things up.

It might not be enforceable but it would take a very brave or wealthy individual to choose to do something that might make Amazon decide to sick their lawyers on you.

Months in court to prove innocence is still a heavy cost to pay.

I "accidentally" worked at amazon for a few weeks when a company I had just joined was acquired by them.

I knew it was time to start looking when I was informed that I had to get prior permission to do ANY open source contributions even on my own hardware on my own time. That's just not feasible logistically and above and beyond the general "don't write open source that competes with us or on our our time/hardware without permission" rule most reasonable companies have.

Fellow Stripe Atlas company founder here. SVB is a bit annoying, but really $25/month is probably not worth your time to worry about unless the company is VERY small.

Even in our situation, where we are a 2-person consulting company that isn't taking any outside investment, and have to run pretty lean (since we only get to eat and have a house every month if we do enough business to cover it), it's not worth our time to switch.

But at a higher level, the Stripe Atlas (and Stripe in general) people have been SO responsive and helpful that I'm surprised they haven't sorted this out yet. It looks like they've even popped up in this thread, so I hope and suspect that will happen soon.

With the AWS credits and how generally easy it was, I would definitely recommend it to others who are looking.

Oh wow I didn't realize there were so many! And yeah, geoparsing is a huge challenge above and beyond "standard" geocoding. Specialization like that is a great asset.

For us, we've really been focusing on the customization of Pelias for people who have specific needs. We have Elasticsearch under the hood which is perfect for that sort of thing, and the nature of customization is that an AMI probably can't do what our clients need. But probably someday it will make sense.