The thing that surprises me is they flew back to Newark for almost 90 minutes. It doesn't make sense to me.
(1) Either you believe the threat is credible and you put it down at the nearest suitable airport in the least amount of time. Say Sydney at about 200km to your west, or FSP at 150km in the direction you're going (not a great fit, but doable). In both cases you could probably land within 20 minutes, a bit more if you aim for Gander (Fun history for that airport, great as an emergency diversion).
(2) or, you believe the threat is not credible. At this point you might as well continue the flight. Flying 90 minutes back does not seem (to me) to meaningfully reduce the risk if someone is actually planning to trigger a bomb anyway.
Thanks, appreciate the details. 99% is far above the amount I expected, and if it specifically hits hard to cache data then I can see how that brings a system to its knees.
Thanks. I imagine there is a (a) a lot of interest in scraping source code, and (b) many requests to forges hitting expensive paths. 99% of volume though, wow, much more than expected.
Maybe I’m naive about this, but I didn’t expect AI scrapers to be that big of a load? I mean, it’s not that they need to scrape the same at 1000+ QPS, and even then I wouldn’t expect them to download all media and images either?
What am I missing that explains the gap between this and “constant DDoS” of the site?
Stellar | Amsterdam, the Netherlands | Onsite (2 days remote OK) | €70-100k + equity | https://stellarcs.ai
Hey, I'm one of Stellar's founders. We're building AI for large contact centers, our primary product is voice.
Contact centers are the last place where companies actually talk to their customers. We listen to calls every week and it's fascinating. AI here helps real people: shorter wait times, 24/7 support, lower cost. We’ve helped companies go from 60 to 98% pickup rate in weeks. We’ve had (human) agents asking us to accelerate our roll out plan because the days with Stellar are so much better than the days without.
We’re all builders. Everybody in our company still writes code. We have one role open:
We are looking for implementation leads that love working with clients. FDEs welcome as well.
This role is perfect if you:
* Want massive ownership at a small team
* Actually enjoy solving hard problems (real-time audio at enterprise scale)
* Think making AI sound human in niche dialects is a fun challenge
Stellar | Amsterdam, the Netherlands | Onsite (2 days remote OK) | €70-100k + equity | https://stellarcs.ai
Hey, I'm one of Stellar's founders. We're building AI for large contact centers, our primary product is voice.
Everyone thinks contact centers are boring. They're wrong. It's the last place where companies actually talk to their customers. We listen to calls every week and it's fascinating. AI here helps real people: shorter wait times, 24/7 support, lower cost. We’ve helped companies go from 60 to 98% pickup rate in weeks.
We're bootstrapped, 10 FTE, cash-flow positive, and growing fast with household names in the Netherlands and Belgium. Doubling our volume every month for the last 4 months.
We’re all builders. Everybody in our company still writes code. We have 2 roles open:
1. We need product minded engineers who can jump between our Go and TS backends and React frontend.
2. We need implementation leads that love working with clients. FDEs welcome as well.
This role is perfect if you:
* Want massive ownership at a small team
* Actually enjoy solving hard problems (real-time audio at enterprise scale)
* Think making AI sound human in niche dialects is a fun challenge
Indeed. Similar accident (USAir 1493/Skywest 5569) shows that thinking exactly.[1] Was easy to pin on the controller, they went far beyond that in their analysis. Almost always impressed with the professionalism of those organizations. I sometimes wonder how software would look if we had such investigations for major incidents.
For some work, similar to the philosophy example of GP, LLMs can help with depth/quality. Is additive to your own thinking. -> quality approach
For other things. I take a quantity approach. Having 8 subagents research, implement, review, improve, review (etc) a feature in a non critical part of our code, or investigate a bug together with some traces. It’s displacing my own thinking, but that’s ok, it makes up for it with the speed and amount of work it can do. —> quantity approach.
It’s become mostly a matter of picking the right approach depending on the problem I’m trying to solve.
Datapoint: I’m running nightly now because the latest 1.2 release has a known crash-on-wake bug when disconnecting an external monitor. Accordingly the issue tracker it was fixed months ago, but it’s not in a release. The nightly is stable though.
Didn’t realize how may projects use libghostty, will try cmux one of these days.
We're doing a lot with the realtime models. Happy to see a new release.
Initial feel from a few calls is that it seems to perform better with alphanumeric inputs. Voice seems consistent. Recognition on a few tests seems to be somewhat better, especially did much better on the two 8-bit 8-kHz mulaw calls I tried.
It does still struggle a bit with some specifics in other languages (e.g., that the Dutch/German pronunciation of 53 'fifty-three' is effectively 'three-and-fifty').
SQLC for me has been able to replace most cases of use an ORM for. It made most of the boilerplate of using plain SQL go away, I get type safe responses, and it forces me to be more mindful of the queries I write.
In an app where we do use an ORM (Prisma), we sometimes have weird database spikes and it’s almost always an unintended heavy ORM query.
The only two things I miss in solutions like sqlc are dynamic queries (filters, partial inserts) and the lack of a way to add something to every query by default (e.g., always filtering by tenant_id.)
Ideally write the hiring manager and not HR. And, write something that makes it hard to not want to talk to you.
1: Minimal hygiene is writing something that shows you read the vacancy (if any). Don't: "I'm interested in the role, CV attached". do: "You want onsite in Amsterdam, I'm living in Milan but already planning to move to Amsterdam for reason X".
2: Stand out from the average applicant. Someone recently applied with a personal website that was a kinda-functioning OS (with some apps). Someone else applied with a YouTube channel hacking an ESP32 into their coffee machine. Someone applied with a tool on their GitHub profile, super well written, in our target language, doing interesting things on the database we're working with, etc., etc. how could I _not_ talk these applicants? All of these are soft signals that show affinity for their work as engineers. Don't: generic application letter combined with 3+ pages resume with too much detail.
3: if invited: get curious (but not overly opinionated/combative) about their stack. Candidates we've been most excited about have come in asking questions on how we're setup, and why we've made certain choices. Don't: expect the interviewer to ask all the questions, or bring only a prepared question that misses the mark.
4: Its a people process, if that's your challenge, work on that. Maybe you share a hobby with the interviewer, maybe you've both solved similar problems in earlier jobs, maybe you both like Haskell, maybe something else to connect over. Connection matters to most hiring managers.
Context: I’m in the Netherlands. With taxes, power is around 25cent/kWh for me. For reference: Amsterdam is around a latitude of 52N, which is north enough that it only hits Alaska, not the US mainland.
I installed 2800Wp solar for about €2800 ($3000, payback in: 4-5 years), and a 5kWh battery for €1200 ($1300) all in. The battery has an expected payback time of just over 5 years, and I have some backup power if I need it.
I’m pretty sure about the battery payback, because I have a few years of per second consumption data in clickhouse and (very conservatively) simulated the battery. A few years ago any business case on storage was completely impossible, and now suddenly we’re here.
I could totally see this happen for the US as prices improve further, even if it’s not feasible today.
Im in this business, and used to think the same. It turns out this is a minority of callers. Some examples:
- a client were working does advertising in TV commercials, and a few percent of their calls is people trying to cancel their TV subscriptions, even though they are in healthcare
- in the troubleshooting flow for a client with a physical product, 40% of calls are resolved after the “did you try turning it off and on again” step.
- a health insurance client has 25% of call volume for something that is available self-service (and very visible as well), yet people still call.
- a client in the travel space gets a lot of calls about: “does my accommodation include X”, and employees just use their public website to answer those questions. (I.e., it’s clearly available for self-service)
One of the things we tend to prioritize in the initial conversation is to determine in which segment you fall and route accordingly.
> On the other hand, if each service experiences the same hour per year of downtime but at different times, then the person is likely to be blocked for closer to 100 hours per year.
I think the parent post made a different argument:
- Centralizing most of the dependency on Cloudflare results in a major outage when something happens at Cloudflare, it is fragile because Cloudflare becomes the single point of failure. Like: Oh Cloudflare is down... oh, none of my SaaS services work anymore.
- In a world where this is not the case, we might see more outages, but they would be smaller and more contained. Like: oh, Figma is down? fine, let me pickup another task and come back to Figma once it's back up. It's also easier to work around by having alternative providers as a fallback, as they are less likely to share the same failure point.
As a result, I don't think you'll be blocked 100 hours a year in scenario 2. You may observe 100 non-blocking inconveniences per year, vs a completely blocking Cloudflare outage.
And in observed uptime, I'm not even sure these providers ever won. We're running all our auxiliary services on a decent Hetzner box with a LB. Say what you want, but that uptime is looking pretty good compared to any services relying on AWS (Oct 20, 15 hours), Cloudflare (Dec 5 (half hour), Nov 18 (3 hours)). Easier to reason about as well. Our clients are much more forgiving when we go down due to Azure/GCP/AWS/Cloudflare vs our own setup though...
I have 1Gbit at home, but almost never reach those speeds when downloading games. It’s one of those cases where it makes sense (I want to play now!), but I’m under the impression the limit is upstream (at steam most likely), rather than on my connection. (I do get those speeds on speed tests, doesn’t seem to be my setup).