yolovoe

> A response needs to be proportionate, and also one needs to account for the causes of the attack in the first place.

You mention a list of reasons, but you forget to mention the most important: that the Palestinians were displaced from their homeland in hordes, often quite violently, in the 1940s to make room for current day Israel.

Just want an accurate depiction of the real reasons, so people are also able to kind of understand (tho not necessarily condone) the Palestinian response.

I have a lot of Israeli coworkers who I like working with, and would never wish them harm. Instead of taking sides, I really wish people understood how we got here, and what we can do to go forward from here. I think a fair path forward would be for both the west and Israel to pay massive reparations of some kind to Palestine, and just slightly re-visit the current drawing of the Israel/Palestine borders. Chances of this happening are slim tho, with western media portraying Palestinians as mindless Hamas terrorists.

I shouldn’t have said droplet. Like sibling says, that’s our internal name for a “server” and not what we use externally.

It’s an internal ec2 term too. We don’t use it externally and I shouldn’t have used it to avoid all this confusion.

Internally, we say droplet instead of host as there are multiple hosts/mobos per droplet these days. It’s no longer true that when you get a metal droplet, you get the entire droplet.

Yes, we internally call servers droplets. We have multiple hosts/mobos in the same server these days so calling them hosts is confusing, and droplet is a really old term here from what i can tell.

The comment you’re responding to is wrong. AWS offers many kinds of storage. Instance local storage is physically attached to the droplet. EBS isn’t but that’s a separate thing entirely.

I literally work in EC2 Nitro.

You’re wrong. Instance local means SSD is physically attached to the droplet and is inside the server chassis, connected via PCIe.

Sourece: I work on nitro cards.

Traditional DBs already kinda support vector DBs via pg_vector extensions and such.

There is a YC startup, latnern, that also built their own extension for postgres that is open source and is better for vector DB use cases: https://github.com/lanterndata/lantern

But yeah! Traditional DBs already support this, if you consider this extension to be part of Postgres.

I work in the core of AWS. Sure, we've lost head count, but I wouldn't expect more outages, at least in the core EC2/VPC space. All the really tenured folks we absolutely need are here in my and adjacent orgs--they're getting promotions, in fact. Really, what the loss in head count changes is what our teams can work on. Less new exciting stuff we can resource--just focus on security, ops, bug fixes, etc. Also, maybe more leverage for the engineers that are still here? :)

I don’t know why you’re getting downvotes. What you’re saying sounds true to me, and I work in the core of EC2.

I am guessing you’re using newer instance types if their reliability is still questionable. Or you have a huge fleet of instances so you see a steady rate of failures every year.

Our failure rate on the commonly used instance types if fairly low. We have several types of failures and in some bad failure cases, live migration isn’t possible and your instance won’t even be restarted.

AWS already asks people to expect failures and plan around this with multi AZ deployments.

If you want stability, sign an NDA with AWS and ask for fleet wide reliability metrics for various instance types. There’s a surprisingly huge variance.

Depends on the team. I work in arguably one of the most core teams at AWS, and I’ll say that most oncalls, I am doing 60 hour weeks at least and getting woken up at night and/or paged in on weekends.

Outside of oncall, I’m constantly pushing back people who try to give me more work. Team is great, manager is great. We’re a team and I can definitely rely on them for support and my welfare. Work life balance can be really bad at times, but we get a good amount of PTO, promotions seem achievable, and my pay at least is really good cause of my manager and perf rating.

I’ve been using Kagi for over a month as a paid user, and it has been slow this week for me too.

I used to have a Pixel 2 XL and then later a Pixel 5a. Went through them really fast as the hardware was pretty bad and the phone would just decide to stop turning on at some point. Same thing happened to a relative I gave a Pixel 5a. Phone didn't last a year.

Don't get me started on the Pixel buds. I got tired of contacting customer support for replacements.

That's when I decided not to buy hardware from Google again, and also stopped using Android. Experience in iPhone has been great so far. Phone's fast despite being several generations behind, don't have to worry about not getting security updates.

I have a 2019 Model 3 dual motors long range. I would not expect to get more than 180 miles on a good day. If it’s raining or snowing, even less than that.

I still like the car and use it for city driving and even road trips with proper planning. Do not trust Tesla numbers.

Don't forget security updates, migrations, correctness and reliability.

It's quick to get an MVP running that "mostly" works in the happy path. It's much more time consuming to get something that thoughtfully and correctly deals with most edge cases, and has some more 9s.

Don't. There's no benefit to using metal as opposed to the largest virt (which will take up the entire server anyways) pretty much. Metal just tends to be somewhat less reliable. Source: I work here.

Is there a path to take AP Calculus BC before senior year? If not, this still seems limiting.

Much of Amazon infra is on AWS. The capacity you request from capacity manager is just ec2 instances underneath including cloud desktops.

I have seen such chains at Amazon. IC -> Manager -> Sr Manager -> Director -> VP -> SVP -> CEO of AWS -> CEO of Amazon.

That's only 7, but some links repeat. For example, I have seen Sr Manager report to another Sr Manager. Likewise, a VP report to another VP, and a Director report to another one.

I work on AWS and interact with a fair bit of Principal and Sr Principals. None are "eccentric." Highly competent, great at processing high volumes of information and context switching, asking amazing questions, ready to help, and really quick to pick up new things, and debug.

I think Sr Principal and Distinguished are achieved by excellence AND tenure. Too much context/tribal knowledge is required so hard for anyone to be effective at a high level otherwise.

To be clear, these people often times deal a lot with operational issues. And they're keeping track of a lot of initiatives and fires. So sometimes I see some lose patience in meetings against managers/leadership. But that's understandable I think given their stress. Happens pretty rarely.

Not true. Most FAANGs don't care about grades or even your major. All that matters is the interview which you can get via referrals. The interview is all leetcode for interns and new grads. I have interviewed at FAANGS and work at one.

For the sites I normally visit, it works well.

GitHub and some famous banks/credit card providers.

Mfa code doesn't autofill, but it's just a click to copy.

I have pro subscription too. Definitely worth it to be able to do 2fa on all sites. Also can require yubikey when logging into Bitwarden.

PhDs, at least in the US, are free. They actually give you a stipend, usually under $80K/year, but more than $50K/year I'd wager.

I want to offer a different perspective. I work on EC2 and my experience is completely different.

Lots of good internal tooling. When something critical to us breaks, we usually cut high severity ticket to get other team's attention.

We rarely have actual customer affecting issues in production, there's no PIP threat, promotions feel achievable within a couple years if you really want them and the extra responsibility, automation is very helpful and we're constantly looking for ways to reduce our operational load.

Yes, testing could be better. Yes, we could have more engineers. Yes, oncall could be less stressful. Yes, I spend 10+ hours on meetings every week. Yes, I write a lot of documents and do a lot if ops to debug issues. I have probably merged just 10-20 lines if code in the last couple months.

But EC2 dataplane is very complicated. Every small change needs to be given a lot of thought. Success and scale bring responsibility. Plus, I've learned so much here. I'm never bored.

And my work life balance is good overall. Slightly less than 40 serious pomodoro hours a week except when oncall.

Ec2 is a very stable system and we keep making it more stable for our customers. Do use it. It's not brittle at all. Expect occasional instance failures and design around that with cross-AZ redundancy and you should be golden.

> as I have seen no real change in the service in the past ~5 years I've used it.

You underestimate the effort it takes to keep a service as large as Twitter running. Constant software upgrades to maintain high standard of security, inevitable technological break-age, deprecated dependencies, operations, root-causing failures, migrations (you can't avoid hardware migrations; hardware will die out), planning fallacy, etc, etc.

I haven't heard of anyone spending 20-60 hours in interviews. Most onsites are remote these days, and the entire interview loop is probably at most 6 hours including phone screen or coding assessment.

I find interviewing to be pretty frictionless for the most part. The hardest part is setting some time aside for for leetcode prep.

I'm sad. I actually donate to signal every month, but now that will likely stop and I'll have look for alternatives.

Rip. This is definitely going to make it harder to get signal adoption. My partner will surely stop using it too now and I'll have to convince my friends to migrate to yet another platform.

I agree with this comment.

I've been on a calorie deficit of 400 for months now and I feel fine. Lost 10 pounds and am pleatueau-ing at 145.

I also work out so my diet is very protein heavy and light on carbs. I don't feel full after meals, but I also don't feel really hungry.

Don't go on an unsustainable calorie deficit. Accept that it'll take time.

I haven't seen any such email. It definitely can be a lot of work at times, esp around re:invent, and I'm sure there are those with bad experience.

I'm just saying, it's worth giving a shot. You might like it. If you don't, switch orgs/teams. You can switch just a couple months after joining if it doesn't work out for you. I switched from my last org quite quickly cause while I had good work life balance, the work was just so boring.

Sad to hear. I agree with legacy code, tho it's not that bad on my team.

When was this? Just to confirm, you're referring to a data plane team and not a control plane team?