kelp

In the US, we invented zoning, mostly to exclude black people from white neighborhoods. And now we use it to prop up property values and continue to keep poor people out of wealthy neighborhoods.

Now I'm speculating, but I wonder if Japan, being mostly Japanese people, didn't have such a large group to exclude from certain neighborhoods? So they didn't entrench the institution of local control and exclusionary zoning?

What alternative news sources would you say are more reliable and truthful?

Also funding the research is one way to ensure the results are shared.

The trouble is if you need VPC peering then it requires a dedicated VPC, dedicated k8s, dedicated instances. Confluent currently only offers one instance size, so that dedicated offering can't be scaled down.

PrivateLink allows for shared VPC and hypothetically a shared k8s. So the cost structure can be better on the Confluent side. Of course scaling down instance types would make a huge difference, but I don't think that's supported currently. The cheaper option is multi-tenant Kafka clusters.

In general, I think VPC peering is a dead end for use cases where you are connecting two companies networks together. It's not great operationally and puts a lot of security / filtering burden on each party.

PrivateLink is a much better option.

It's been 10+ years since I tried CPAP, but I could never get to a place where I'd sleep through the night with it on. I'd always take the mask off in my sleep. I tried more than a half dozen different masks and I could never get one comfortable enough to sleep with. It always felt like it made the situation worse.

Over the years I think I've been to 4 different doctors for sleep apnea. Had 3 in lab sleep studies and a few take home ones. I always came away somewhat skeptical of any data obtained from the sleep studies, especially the in lab ones. The situation was just so different from how I'd normally sleep.

I only have mild sleep apnea and I'm not overweight. So I ended up going in for surgery twice, with different doctors. Got a turbinate reduction, so I could breath through my nose better and they somewhat straightened a deviated septum. Had the pillar procedure, and got a mouth guard made.

The mouth guard has changed my bite, but overall it does improve my subjective sleep quality, and objectively, the stake home sleep study showed substantially improved numbers. Though I'm told I'll still stop breathing and gasp for air in my sleep. So It's improved on the issue but not eliminated it.

It still competes for fab space and raw materials.

I'd love it if there were automated tickets for this. But California can't even get it together to allow automated speeding tickets, a bill for this just got killed.

In SOMA in San Francisco I'll often hear motorcycles drive by that are so loud they set off car alarms along their path.

And don't get me started on the cost/benefit of car alarms.

Having done both, I think I mostly agree with you. And I'm a big proponent of having your engineering team focus their efforts on building and maintaining the product you are selling to customers.

Avoid doing undifferentiated work. Outsource it when you can. Focus on the core product. I think this is especially true as you're scaling a company in the current SWE labor environment. If your business is growing quickly, you probably have money, and can get more funding when you need it. But hiring more SWEs is always a challenge. That is your scarce resource. Don't waste it on undifferentiated work.

All that said, at larger scale and more mature businesses. I think the core thesis of the article makes sense. You may be in the slower growth part of the S curve, but you can still increase your company value and profitability substantially by increasing margins. One way do do this is to invest in cheaper infrastructure.

Then you're taking on some undifferentiated work, but in service of better margins.

Yes and, it depends.

Last time I was procuring racks of servers, it was about a 6 week lead time, sometimes more. So yeah, you have to do a lot more capacity planning, and probably keep capacity in reserve for things that are unexpected.

I've had to go around to every engineering team and try to get them to tell me how much gear they might need in the next 1-2 quarters. They rarely know, so it's a lot of guess work.

So in a situation with a quickly growing product, that grows in an unpredictable way. Or a really new product where you just have no idea what the adoption is going to look like.

Then yeah, getting those new instances right now is really really important. At Segment we very often needed more instances in a huge hurry due to some customer load spike.

And sometimes AWS ran out of the instances we needed in the region we were in. So we had to get creative to use other instance types.

Also the cloud provider pricing structure heavily incentives you to actually do some capacity planning. On AWS, Savings Plan gives you huge savings.

But if your workload is fairly predictable, then this on demand benefit isn't nearly as compelling and at the right scale, it makes sense to start buying servers to put in your own datacenter.

Also in my experience, on-prem infra, on relatively cheap gear like Dell servers is highly reliable.

Yes, you have to plan, yes you have long lead times to get new gear, DC space, etc. But once it's running, failure rates are pretty low. At least in the single digit thousands and servers.

I've had to deal with much more frequent and odd types of failures on cloud infra than with on-prem.

I don't know how every company does it. But I led the datacenter and networking teams at Square from 2011 to 2017. In that time we went from 1 DC cage with 4 server racks to 4 US DCs, one in a Japan and a couple of network pops. A bit more than 100 server racks total.

My team had 2 guys doing SiteOps. They would travel to the various DCs in the Bay Area and Virginia and do all the maintenance, new installs, etc. And sometimes we'd lean on the colocation remote hands to do a few things.

We had about 5 network engineers, that also handled the corporate network. (12 offices and a network backbone that connected east and west coast DCs, offices, etc).

And maybe 2 SWEs who handled things like our host OS install system, etc. Basically the next layer above the hardware.

So 9 people that were required to run all of that stuff. But really, NetEng ended up spending like 70% of their time on corporate network things because we'd add offices faster than datacenters.

So if we focused on production only, we really needed about 6 or 7 people total.

I did the math a few times (every single year) and compared our costs, including people, to the costs of moving to AWS 3 year reserve instances.

Doing it ourselves was always half the price.

Of course the difference here was we built on-prem from the start. So there was no repatriation that had to happen.

Since then, I've been responsible for large cloud infra on all 3 major providers and learned a lot about what kind of discounts you can get when you're in the double digit millions in annual spend.

I still think, at a scale of single digit thousands of servers, you'd be cheaper on-prem, fully loaded. But admittedly, I haven't run the numbers since 2017.

What I know from talking to former Dropbox insiders is Drew really wanted to be running a consumer company. He really resisted a push to SMB and Enterprise, even though, at least to me, that seems like the obviously better business.

So not sure if it's so much that the product stalled, but that leadership actively didn't want to move in that direction for too long, then lost the advantage.

Instead they spent a bunch of energy on Carousel and Paper. (I don't have any idea how much of their eng team was working on those things)

In my experience it's pretty common to stretch your infra out much longer than 18-24 months. Often finance has a 3 year depreciation schedule, and depending on your needs, you can keep existing workloads on existing hardware for many more years.

The last time I ran physical infra, we had sever racks that I'd originally bought, running in production 5+ years later.

Once you're past the depreciation schedule, they are basically free except for power and space. Yeah, at some point and scale, it can make sense to get new gear that is more power and space efficient to pack more into the same power and cooling budget.

AWS still lets me launch c1-c6 instance types. So they still have the older generations sticking around. Yeah, the newer ones are usually more cost effective, but you do have to do work to migrate to them.

That sounds right. But then I'm having to compile all the packages I need, which makes it even much much slower than brew when binaries are available.

I dislike it because it’s really slow to do everything. Even printing help text is slow.

Contrast with pacman on Arch, which is incredibly fast at nearly every operation.

Unfortunately I’ve found all the package managers for macOS to be lacking.

brew is slow, but has packages for most things and generally up to date.

fink packages seem a bit out dated last I checked. At least the ones I cared about.

MacPorts is also slow and somewhat out of date.

pkgsrc doesn’t have Apple M1 binary packages available yet.

I haven’t tried Nix.

Sometimes I’m tempted to try my hand at writing my own package manager for macOS, but getting a critical mass of packaged software seems quite hard.

This reminds me of how Steve Jobs would talk about the need for liberal arts influence in technology. I feel like so much of this blockchain and cryptocurrency stuff is made purely looking at the tech, with either no thought to the actual incentives involved, or a total misunderstanding of them.

I currently have two plots farming and it looks like this:

  Farming status: Farming
  Total chia farmed: 0.0
  User transaction fees: 0.0
  Block rewards: 0.0
  Last height farmed: 0
  Plot count: 2
  Total size of plots: 202.674 GiB
  Estimated network space: 7357.090 PiB
  Expected time to win: 20 years and 1 month

In dollars, almost certainly not. Maybe in number of BTC that traded hands?

I have similar memories of lilo. Kind, unassuming, and helpful. Me and some college friends had a small channel back in the early 2000s, and lilo would occasionally pop in and say hello. He was always nice. At the time I wasn't sure how he was able to spend so much time on IRC.

Was trying to find evidence for this and it doesn’t seem like NASA agrees with you: https://www.nasa.gov/feature/goddard/2020/what-will-solar-cy...

There are some minor tweaks to what port range syntax is acceptable: https://www.openbsd.org/faq/upgrade69.html

First, I worked at Square from 2011 to 2017 and have been very invested in the company and the mission.

Second, I was super interested in Bitcoin around 2010-2011. Doing a little bit of small scale mining myself. I've since become very negative on Bitcoin for a few reasons. 1. Insatiable energy needs, and the environmental impact of that. 2. It's a solution looking for a problem, and not a good solution at that 3. It's a world filled with charlatans and get rich quicker. Pump and dump.

Overall I think you're exactly right, it's like the Tobacco companies telling us cigarettes are good for you. It's motivated reasoning, or just straight up propaganda, and green washing.

And before they published this, I was already seeing people use this exact line of motivated reasoning, that mining encourages green energy development, to justify it. So now I think Square, Jack, and Elon just gave that story more credibility.

Here are two takedowns of the Square argument, sorry both are paywalls, but googling the headline got me to both: https://www.bloomberg.com/news/articles/2021-04-22/what-musk...

https://www.ft.com/content/0448b44d-1d78-48f8-8ca8-6edae7976...

As someone who has access to and regularly works with (pays) tax professionals and financial advisors, I've yet to be able to take advantage of much, if any, way to avoid paying any tax.

Most of the things I'm aware of, and have been advised of, are things like QSBS (Qualified Small Business Stock) which I've been able to claim once. In that case it was a 5 figure gain. So the tax benefit was not particularly amazing. Yeah, others have been able to benefit much more from this. But it's a pretty narrow situation where you can.

I've recently early exercised some ISOs, so if this proposed tax change didn't pass, I'd have the long term cap gains rate.

I think there are some interesting things you can do with charitable trusts, but I think you're mostly deferring taxes, and I haven't had a situation where it made sense.

But all in all, in the years that I've paid, what I think, are a pretty competent set of financial professionals, I've yet to come across any magical way to avoid paying any taxes. I've actually paid a large amount of taxes and have to ensure my investments and finances are planned so I can pay the tax bill when it comes due.

I think most stories we hear about the wealthy not paying any taxes are either tax fraud, or substantial capital losses that offset all gains.

In the capital loss situation, that's probably a temporary thing for that person, otherwise they won't be wealthy for long.

I'm glad this is being shared widely, because I agree with it.

That said, I have to snark a little about it, because I was in high school, in the 90s, when I came to the same realization about why the death penalty is wrong. So this seems pretty obvious to me.

Our justice system is not reliable enough to have the death penalty.

Ryzen 5 5600x and Ryzen 7 5800x prices / stock have about equalized lately. So they are pretty easy to find at MSRP. You can currently get a Ryzen 7 5800x from many major retails for MSRP. The Ryzen 9 5900x and 5950x are harder to get.

It's GPUs that are nearly impossible to get right now. I've been trying for weeks to get one for a friend. I'm intently watching the stock notification Discords. There are frequent restocks, but they seem to sell out in seconds.

It seems to be a net negative to society to me. One of those cases where a small group gets rich, while everyone else pays the externalities.

I recently worked at a single digit billion dollar valuation SaaS provider and we had to run everything on AWS, GCP and Azure, to be where the customers were.

Total cloud spend was in 2 digit millions per year.

Many hundreds of k8s clusters, all using each providers k8s managed service.

My general high level take is this:

* AWS

Products mostly work quite well. Their UX is terrible and very inconsistent between products. But things mostly work, and their support is generally excellent, especially when you have a TAM (Technical Account Manager) who you can reach out to at any time. They will help you navigate any support issues, and ensure you get a quick resolution. But AWS stuff is generally very complex, overly complex in my opinion.

Also at scale API rate limits just kill you, and AWS continues to struggle to provide any real visibility into API rate limits. I'm told that large services internal to AWS have to work around this by building their own caching layer in front of any control plane APIs. Also the api limits are at the account boundary, so you have to start doing account sharding.

GCP:

Has better UX, more consistent experience. Much better visibility into limits and things like that. You still probably end up having to do project sharding at scale to work around limits. We continued to run into a lot of issues with GCPs load balancers blackholing traffic, and it was never really resolved. I think their support is generally worse than AWS. I've had substantially worse support experiences with GCP than AWS at 2 companies now. Mostly support not being particularly useful, and not resolving the issue. As a customer it feels like Google has struggled to adapt their culture to the needs of real enterprise customers. AWS has this much more figured out. But my GCP account teams have always been quite good.

Azure: The worst of all 3. Lots and lots of issues with their k8s service, low limits on the number of nodes you could deploy. k8s 1.18 supposedly fixed a lot. But their answer was always just that you have to upgrade. Their support engineers were frequently gave us actively bad advice that would have resulted in full customer outages if we'd followed it. The engineers on my team fortunately didn't listen and instead figured out how to fix issues themselves. Also frequently ran into various limits and you need to start thinking about subscription sharding.

Of the 3, I personally prefer using and interacting with GCP. But their support or is still certainly worse than AWS. That said, I always felt bad for our TAMs at AWS. It felt like a non-stop job where you had too be available at all hours to deal with unhappy customers. They usually gave us fantastic support, but I wonder at what personal cost.

I'm sorry you've had this experience on the corporate side.

I see in one of your other comments that you work for yourself now, so this unsolicited advice probably doesn't apply to you. But I'll leave it here anyway.

I've had plenty of candidates ask me how I or the company help employees grow, and what it takes to advance.

I typically see this as a good sign and I explain the career ladder, explain how promotions work. Explain how I would help in their growth.

If they don't have good answers for this, it's quite a red flag.

You can also ask about collaboration and what kind of work is rewarded.

> Sharing knowledge in the business world, never. That's a great way to lose a job.

If you're working at a functional organization that rewards growth, never sharing knowledge will ensure you put quite a low ceiling on your advancement.

I've written countless promotion justifications. Been on countless promotion review boards at several very successful tech companies. Being the best programmer, or what ever, is only going to get you so far. Advancement comes from teaching and leading others. You do that by sharing knowledge.

Yeah, and it's particularly hard when you're still ultimately responsible for the result, but others are doing the work. That certainly brings some amount of stress. But also the money gets bigger and bigger.