I don't think Kafka using eschewing fsyncs is a bad thing; I'm aware of the risks. What I'm pointing out, and what got Mongo killed in the court of public opinion, was saying "our database is blazing fast because we turned off fsyncs".
Benchmarking a system that fsyncs every write to one that doesn't isn't an apples-to-apples comparison. You are free to make the argument that you might not need them, but if you are benchmarking systems and one of them fsyncs by default, that is the level of durability I'm going to expect, otherwise I can assume the other guy will be just as fast if he turns off fsyncs as well.
This ^^^ My answer to this question would have been a VERY weak "Yes" before the Twitter disaster. Now that we're seeing the true Elon alongside real engineer feedback, it's a HARD no.
You don't know anything about this guy, his employment history, if was underperforming in the past, etc. You read yet another hit piece on Elon because he's taking out the trash at Twitter and all of a sudden this one example has TOTALLY changed your opinion. You are being manipulated.
You really can’t conceive of a world where Elon’s actions soiled his reputation?
You think all of this is just some narrative being pushed, or are you just sensing a shift in public opinion and since it’s a deviation from the norm you are assigning it to some unknown “force?”
Has his management style changed? There are plenty of stories about him cracking the whip, being a total authoritarian jerk, etc at Tesla. Where was the outrage then? The only think that had changed is he's fallen out of favor and "public opinion" is being shifted on purpose.
> See all the negative press about Elon and Twitter. You think this is organic?
Well, it certainly hasn't been going great. I have no idea if it's organic, but the tech press reporting bad news about an ongoing tire fire is expected. Why would you even need to manipulate the news, when the company itself is generating bad news at such a rapid clip?
Yes. A lot of people are being affected by his poor choices and a lot of people are watching said outcomes play out. This means there will be a significant number of people writing about it.
They explain pretty clearly that this is static memory allocation. In other words, a calculated amount of (mostly) contiguous memory is allocated at startup and used very carefully, relying on disk to supply the dynamic nature of database load semantics.
Per the article: "(Currently it’s determined even before startup, at compile-time, but startup is the important point since that is the first time that memory can be allocated.)"
Sooo are we sure you can even change this via proc restart? This is saying the limits are built-in during compile...
They are currently compile time settings. That may change in the future to be more user-friendly. :) But what won't change is that the size is fixed at startup.
That totally makes sense. I think you'd have a miserable time supporting this at scale if a re-compile is needed every time a new workload requires a tweaked setting or two. Config based static allocation is the best of both worlds.
I'm sorry it was perceived as such. I should have been more mindful. I genuinely intended for the substantive part of the post to be about our frustrations as programmers navigating the business world. It felt like the short introductory sentence was necessary to establish context (I'll remove the link, but leave post intact so other viewers aren't confused). Still off topic but, at the time, it seemed to be an on-brand discussion for HackerNews. What we were really phishing for was rapport from other engineers that we aren't crazy. I even feel vulnerable putting our project out here, at this stage, and the quick cost-benefit analysis in my head was this was a net-neutral.
I doubt Steampipe knew we existed before this post. It seems like fate because I stumbled upon Steampipe just last week. I deliberated how to craft a not-awkward email along the lines of "Hey guys, we just realized we're tackling the same problem. Cheers." When I made the original post, I felt like it was the less awkward way of saying hi but now I'm not sure. At any rate, I hope you understand we did it in good will and not malice.
Edit: I also hope "Best of luck to Steampipe and whoever else is working on this problem" doesn't get misconstrued as being a passive aggressive jab. Our team would honestly be thrilled if all the friction points of IaaS goes away, regardless of who solves it. As a reverse-ad, I'll say a few nice things about Steampipe that stood out to me: written in Go, supports querying HackerNews, SQL/Tables are a really good medium.
Not sure what browser you use, but in most you can select what you wanna search for, click "Search on $searchEngine for $term" and there you go! For PQC, I get Wikipedia link with "PQC can refer to: Post-quantum cryptography" in the description as the 3rd result on Google.
Not sure what classifies as "fair amount", but for me it took about 1-2 seconds to find the Wikipedia link ;)
I agree that it is not a lot of work for a single person, but if you add it up over 100,000 readers (just a ballpark guess, I am sure dang can tell us exact numbers), it sums up to at least 2 days of cumulative wasted time, assuming that everyone looked it up. Obviously, not everyone will look it up because of laziness or indifference, but those readers will not understand what the title is about, which is not an ideal situation either.
A similar situation arises with trains, where it is often better to not hold open the door for someone who is late by a few seconds, as the cumulative delay for everyone else in the train exceeds the waiting period of the single person for the next train.
Are people generally cool with unsolicited PRs to "editorial" content? I'd have assumed that stating or not stating something in a README is mostly an intentional decision.
I doubt there's a universal answer to that question, but I think most projects tend to overlook important information because the participants have been too deep in the weeds for too long. You tend to forget what newcomers won't find obvious about your tool.
The article body and headline are (of course) at odds IMO. The headline is very much "doomscroll" material while the article points out that interference could basically manifest as having to rely on secondary systems and protocols to land. If I'm missing something then happy to be corrected :D
Airline accidents almost never have a single cause. It requires multiple failures to align before you have disaster. Malfunctioning radio altimeters could be one of those factors.
That said, this is Boeing's fault. They need to clean up their act ASAP, and it seems like they've been banking on the FCC covering up their mess and are now running around with their hair on fire.
A reasonable stopgap may be to simply not allow 5G towers to use the frequencies ranges in question within some radius of an airport (20 miles?) for a few years until Boeing fixes the problem.
A 20 mile radius of any airport likely covers a significant portion (60-70%) of all urban/suburban population. They might as well just give up on that spectrum at that point.
https://jack-vanlightly.com/blog/2023/4/24/why-apache-kafka-...
Kafka has never tried to hide that fact and it does not, in any way, make Kafka unsafe.