Good point about the M x N problem reduction, but this glosses over a critical limitation. While MCP does turn integration complexity from M x N to M + N for the protocol layer, authentication and authorization remain stubbornly M x N problems.
Each MCP server still needs to handle auth differently depending on what it's connecting to. A GitHub MCP server needs GitHub tokens, a database server needs database credentials, an email server needs SMTP auth, etc. The client application now has to manage and securely store N different credential types instead of implementing N different integrations.
So yes, the protocol complexity is reduced, but the real operational headache (managing secrets, handling token refresh, dealing with different auth flows) just gets moved around rather than solved. In some ways this might actually be worse since you now have N different processes that each need their own credential management instead of one application handling it all.
This doesn't make MCP useless, but the "M x N to M + N" framing undersells how much complexity remains in the parts that actually matter for production deployments.
Just my opinion but, server‑side rendering never really went away, but the web is finally remembering why it was the default. First paint and SEO are still better when markup comes from the server, which is why frameworks as different as Rails + Turbo, HTMX, Phoenix LiveView, and React Server Components all make SSR the baseline. Those projects have shown that most dashboards and CRUD apps don’t need a client router, global state, or a 200 kB hydration bundle—they just need partial HTML swaps.
The real driver is complexity cost. Every line of client JS brings build tooling, npm audit noise, and another supply chain risk. Cutting that payload often makes performance and security better at the same time. Of course, Figma‑ or Gmail‑class apps still benefit from heavy client logic, so the emerging pattern is “HTML by default, JS only where it buys you something.” Think islands, not full SPAs.
So yes, the pendulum is swinging back toward the server, but it’s not nostalgia for 2004 PHP. It’s about right‑sizing JavaScript and letting HTML do the boring 90 % of the job it was always good at.
I had this happen to me today, at first they claimed it was linkedin, turns out it was a company called "Rocket reach" rocketreach.co. They mine data from everywhere and you have to "claim" your profile to submit a takedown request.
> The CDC should immediately change how it reports flu deaths. While in the past it was justifiable to err on the side of substantially overestimating flu deaths, in order to encourage vaccination and good hygiene
Yeah... except this is exactly what they are doing for COVID deaths, read the below.
One of the best experiences I had was actually going through a different site which seemed to have even more options than Healthcare.gov, https://www.policygenius.com/health-insurance
I'm sure there's more as well, but this definitely helped several friends of mine. Seems like these kind of things would have been impossible without large swaths of the ACA.
"Why does calloc exist?" That's the title of one of the articles linked on the front page right now. I would challenge anyone to show us where the NYT, Economist, Drudge, Huffington Post, etc have anything like this. They don't. Why not? Because it's not what people come there to read about. I would argue this is "Hacker News". If you want politics, what's wrong with the 10k other sites dedicated to these topics? To note, all of the aforementioned have tech sections discussing topics like the ones you mentioned here, but none of them have anything like Hacker News does on a daily basis. This isn't censorship anymore than Cosmopolitan magazine not covering Nascar very often (if at all). Know your audience.
In my opinion, these types of articles should stop making the front pages of Hacker News. They aren't generally relevant in anyway to the greater community of readers on here. There are plenty of different sites that specialize in non-geek culture related things, but that isn't why the bulk of us come to this site. Just my opinion, however I also agree, I could just as easily not click on it.
>"Internationalization" is 20 letters long, but it will be cracked in seconds by even a moderately sophisticated attacker. (zxcvbn gives it guesses_log10 of 4.34708)
Literally nothing to do with the article and an absurd choice for a password to make your (misguided) point. Length does trump complexity, however once again I'll repeat, the article doesn't say complexity doesn't matter. It does. It says it does.
Sorry my man, I think you missed the point of the article entirely. I also think your knowledge about how passwords are cracked in the wild is off base. Your theoretical thought experiment here isn't how it's done. Also the Dropbox password calculator you provided proves it. Every single character added to a decent password adds guesses_log10 assuming moderate complexity.
>My point is that 72^8 and 72^22 is an invalid comparison to determine the relative strength of those passwords.
That's fair, but you're talking about directly attempting to crack as opposed to rainbow tables, which I believe was the authors intention, mapping the full key space. In this case, the exponents still hold.
>Do not follow this advice on passwords.
Additionally, maybe your first comment's point wasn't well articulated, since the author's work has proven true in your own tests for the passwords given, length trumps complexity. I would also argue that he doesn't say anywhere do not use complexity, he specifically points out however that banks use complexity as a mask of security while limiting length.
Seems like you decided to quote the article, yet ignore the actual advice.
>Password length is 99% of password security. Password complexity is a distant second when it comes to modern password security.
He doesn't say to use a common 10 letter word with no complexity, which you infer with your comment. It's also comparing 72^8 with 72^22. The point of the article is that length trumps complexity. Not sure how you came to your conclusion.
Exploding offers are necessary. I agree they should be discussed with the candidate at the interview so there is full disclosure. That being said, I have a role I need to fill and I'm aggressive with hiring. If the candidate doesn't want to work for my company on it's merits (assuming my offer isn't way off base of course) then I want to move on to someone who does. The candidate's time is important, but so is the company's.
Ok, so I'll be the one to say it. It seems to me that no one who's commented here served in the military. The threats that were given to this women are horrific, yes, she didn't deserve any of them. That being said, she should have never taken that picture, regardless of what excuse she had for taking it. And that being said, she should have known better than to post on social media. And that being said, she should have known about privacy settings. This is equivalent to walking around shouting racist terms on the streets and hiding behind free speech after someone attacks you. She didn't ask for any of the threats she received, but she also had exceptionally poor judgement.
Each MCP server still needs to handle auth differently depending on what it's connecting to. A GitHub MCP server needs GitHub tokens, a database server needs database credentials, an email server needs SMTP auth, etc. The client application now has to manage and securely store N different credential types instead of implementing N different integrations.
So yes, the protocol complexity is reduced, but the real operational headache (managing secrets, handling token refresh, dealing with different auth flows) just gets moved around rather than solved. In some ways this might actually be worse since you now have N different processes that each need their own credential management instead of one application handling it all.
This doesn't make MCP useless, but the "M x N to M + N" framing undersells how much complexity remains in the parts that actually matter for production deployments.