Readit NewsOut of curiosity: what are the scale limits of FoundationDB? What kind of issues would it start to have? For example, being able to store all of Discord messages on it?
I see blog posts of Discord moving to Scylla and ElasticSearch, but I wonder if there would be any difficulties here.
Redesigns are often self-indulgent. Designers like that they get to do something new, employees who stare at the same software every day get to change things up, and managers get a highly visible change they can point to as evidence of their "impact". What's best for the users is often not a top concern.
I have rarely seen UI changes where users were genuinely excited to have a new UI with the understanding that they'd have to learn new paradigms. Most web apps should still be Bootstrap apps, but of course then you can't put that on a giant dashboard wall at a conference ;)
Our server bills are in EURO.
Our salaries are in EURO.
Our subscription for business operations are in EURO.
Our accountancy costs are in EURO.
It helps that our focus is on European customers, but that said, it is hard to justify going with USD pricing.
I've only ever worked at startups before, but HashiCorp itself left that category when it IPO'd. Each phase is definitely different, but then again I don't want go back to roadmapping on a ridiculously small whiteboard in a terrible sub-leased office and building release binaries on my laptop. That was fun once, but I'm ready for a new phase in my own life. I've heard the horror stories of being acquired by IBM, but I've also heard from people who have reveled in the resources and opportunities. I'm hoping for the best for Nomad, our users, and our team. I'd like to think there's room in the world for multiple schedulers, and if not, it won't be for lack of trying.
I would love to be able to use a distributed log like Kafka/Redpanda since it's HA out of the box, but it simply does not fit that use-case.
Too many people end up with their own half rolled pubsub via things like grpc, and they'd be far better off using this, particularly in the early stages of development.
Equifax had its entire response to its breach on a different domain, the kind of thing we tell people to watch out for.
https://www.equifaxsecurity2017.com/
This looks like phishing. But it is legitimate.
But even if you follow all of these best practices there are still powerful attack vectors. A threat actor could host their phishing page on an unrelated (compromised) domain with good domain reputation, in that case you wouldn't even know about that site until the first email or SMS hits your customers. Or the threat actor could use one of the many file-hosting or website services to create their site and host it on a shared third-party domain with perfect domain reputation (e.g. amazonaws.com).
And then there's incentive: It's no the companies that suffer financial losses, it is their customers. If you were talking about their employees being phished that would be a different story. Same thing for Google Safe Browsing: Their incentive is to protect against most of the obvious phishing, without any false positives, ever. If they are slow to detect something they won't suffer any losses. If they generate a False Positive their Chrome browser might suffer significant reputational damage if a popular legitimate domain is blocked.
Threat actors use Cloudflare and other services to gate their payloads. That’s a problem for our customers who are trying to find/detect things like brand impersonation and credential phish. Cloudflare has been completely unhelpful. They just don’t care.
Disclaimer: We operate in this space so we obviously have an interest in being able to detect these threats going forward.
The one issue I remember is: On ES 5 we once had an issue early on where it regularly went down, turns out that some _very long_ input was being passed into the search by some scraper and killed the cluster.
The only bigger issue we had was when we initially added 10 nodes to double the initial capacity of the cluster. Performance tanked as a result, and it took us about half a day until we finally figured out that the new nodes were using dmraid (Linux RAID0) and as a result the block devices had a really high default read-ahead value (8192) compared to the existing nodes, which resulted in heavy read amplification. The ES manual specifically documents this, but since we hadn't run into this issue ourselves it took us a while to realise what was at fault.