I hate the idea of MCP servers being their own OAuth providers and IMO I wouldn't use this. MCP servers just shouldn't have to handle OAuth user management. The only reason PostgreSQL is needed here is to store OAuth tokens for its users. It works though ¯\_(ツ)_/¯
The draft spec[1] – soon to be published AFAICT – flips this on its head and says "no, the MCP server is an OAuth2 protected resource, just go and talk to this authorization server and I'll accept its tokens". The MCP server doesn't need to handle anything related to auth. That's much saner, and would recommend people build towards _that_ particular future in mind.
But also broadly speaking: I strongly believe the mental model needs to move to MCP servers are URLs. It should just be extra endpoints and controllers on top of your app. I don't want to `npm install mcp-your-app` or go through someone else's implementation, I want to hit `https://your.app.com/mcp` directly.
I guess it's fine having the separate infra for an MCP server used to connect to 3p services... but fingers crossed, your 3p services starts exposing MCP endpoints directly.
Just like any 3rd party server, it needs its own auth i think. like Sentry MCP. You want to track your own, authenticated servers on Sentry. So you need to auth with your own creds.
Love his series, but you really have to keep in mind that his testing methodology is "reductionist": a microphone's quality can't just be distilled to its EQ response. Phase, transient response, clipping, etc. are also part of the equation.
edit: My "case in point" moment is Jim's (excellent!) DIY amp section in this video: https://youtu.be/wcBEOcPtlYk?si=jkehIfyo6AgeTLUo&t=918. Its EQ indeed sounds like the big names, but I'm sure you'll also notice how its dynamics also sound so thin. That's likely because solid state clipping != (saggy) tube overdrive.
The takeaway for me on all his videos is that yes, these things are different, and they make a difference. But the difference is so subtle and nuanced that its nigh on impossible hear it, especially in the mix, played on a CD, over a stereo in a less-than-ideal treated room.
In one of his amp cab videos he has the appiphany that all his tone chasing was for naught, because he failed to consider that each and every sound he hears has been recorded. He cannot replicate the tone of how an amp or cab or speaker or guitar sounded, because that sound was recorded, where the mic, preamp, console and recording medium all added their own influence, and him listening to an amp in the room is not how that amp actually sounded. And live sound is a completely different animal all together!
Here's a thought experiment. Think back on how that statement would have sounded like to past-you, 3 years ago. You would probably have dismissed it as bullshit, right? We've gone a long way since then. Both in terms of better, faster and cheaper models, but also how they're being intertwined with developer tooling.
You could have said the same for crypto/blockchain 3-4 years ago (or whenever it was at peak hype).
Eventually we realized what is and isn't possible or practical to use blockchain for. It didn't really live up to all the original hype years ago, but it's still a good technology to have around.
It's possible LLMs could follow a similar pattern, but who knows.
It created a speculative asset that some people are passionate about.
However, if you saw the homepage of HN during blockchain peak hype, being a speculative asset / digital currency was seen almost as a side effect of the underlying technology, but it turns out that’s pretty much all it turned out to be useful for.
As you inadvertently pointed out, AI improvements are not linear. They depend on new discoveries more than they do iteration. We could be in either out of jobs or lamenting the stagnation of AI (again).
After an innovation phase there is an implementation phase. Depending on the usefulness of the innovation, the integration with existing systems takes time. It is calculated in years, tens of years. Think back on the 80-90s, where it took years to integrate PCs into offices and workspaces.
From your comment, is sounds like you think that the implementation phase of LLMs is already over? And if so, how do you come to this conclusion?
It's not as if we have no idea how to make use of AI in programming. We've been working on AI in one form or another since the 70's, and integrated them with our programming workflow almost as long (more recently in the form of autocomplete using natural language processing and machine learning models). It's already completely integrated into our IDEs, often with options to collate the output of multiple LLMs.
What further implementations of integrating AI and programming workflows have LLMs shown to be missing?
You can imagine all sorts of things, and then something else might happen. You can’t rely on “proof by imagination” or “proof by lack of imagination.”
We shouldn’t be highly confident in any claims about where AI will be in three years, because it depends on how successful the research is. Figuring out how to apply the technology to create successful products takes time, too.
Ten years ago when Siri/Google/Alexa were launching, I really wouldn't have expected that 2024 voice assistants would be mere egg timers, and frustrating ones at that - requiring considered phrasing and regular repeating/cancelling/yelling to trick it into doing what you want.
A 10x near future isn't inconceivable, but neither is one where we look back and laugh at how hyped we got at that early-20s version of language models.
It also might be that the language everyone uses 20 years from now that gives a 50X from today is just being worked on right now or won't come along for another 5 years.
The way people who would have thought that humans could never fly were not completely wrong before the airplane. After the airplane though, we are really talking about two different versions of a "human that can fly".
OK that’s neat but boils down to “here’s a cool game”. I was expecting a double blind study that measures some concentration metric vs a placebo intervention.
I'm sure they intend to do something like that, but unfortunately time/funding is probably getting in the way. Making an app like that is not exactly cheap. You need either the right combination of skills or a lot of trial an error, which is either high rate times short time, or low rate times long time. So they probably released this intermediate work to try to gin up some interest to get more funding.
Good luck to them. Never really worked out that way for me in my efforts.
Please do whatever you feel like doing. If you like the aesthetic and it fits the overall design, why not? Don’t let some HN commenter tell you what you can’t do.
Recently switched to WezTerm and I'm very happy. Was using kitty before that – loved the set up and simplicity coming from iTerm2. WezTerm is leaps and bounds better in terms of what comes out-of-the-box. My terminal config is short enough to sit all in one screen on my editor. After that, the terminal just... gets out of the way and I don't need to think about it.
But the straw that broke my back with using kitty was, I'd end up encountering issues or trying to recreate some of iTerm2's features, only to end up time and again on kitty's maintainer's terse and dismissive comments.
e.g. IIRC his answer to "How do I set up tmux with kitty?" was something like "Don't, tmux is dumb" and closing it. Eventually I gave up.
> e.g. IIRC his answer to "How do I set up tmux with kitty?" was something like "Don't, tmux is dumb" and closing it. Eventually I gave up.
Heh, I switched from Kitty to Wezterm due to the exact same types of comments from the maintainer. It's his project of course, and he's a great programmer, but some humility wouldn't hurt.
> the exact same types of comments from the maintainer.
Kovid really bugs me and is a reason I turned away from kitty too. I saw his character when looking up tmux issues. He's brash like Linus, but at least while Linus is calling you an idiot he'll tell you a better way to solve your problem. Kovid seems to think tmux is really about splitting panes and peoples' main draw to it isn't about persistence...
On a side note: I really don't trust devs who reply to issues and close them. I get wanting to remove the issue from the task list, but just set up an action for stale issues (which has an added advantage of pinging the user who may have just lost the message). Otherwise let the user close because they might have follow-up questions. It's just disrespectful and always a red flag. I know lots of users are dumb (I literally just got an issue on a research project with someone asking how they fine tune our model...), but noobs are wizards in training. You don't have to be nice, but don't be mean either. Plus, you'll just piss off people who could end up helping you. And if you don't want help, I expect your project to decay when you get bored. Definitely not what I want from a terminal
"Are you sure you want to close this window",
meant to only trigger in interactive scenarios like ssh or htop, triggered on the regular shell sometimes. Not even consistently
> The gcc people have a BAD attitude. When the meaning of "inline" changed (from a "inline this" to "hey, it's a hint"), the gcc people never EVER said "sorry". They effectively said "screw you".
> Comparing it to the kernel is ludicrous. We care about user-space interfaces to an insane degree. We go to extreme lengths to maintain even badly designed or unintentional interfaces. Breaking user programs simply isn't acceptable. We're _not_ like the gcc developers. We know that people use old binaries for years and years, and that making a new release doesn't mean that you can just throw that out. You can trust us.
Which I think is an important lesson here. About how when you build tools, people build around you and what they have to work with. But I'm surprised this attitude is not more common, because I don't know a single person who is unfazed when changes happen that break their programs/workflow. It's reasonable for someone to be upset. And not a single person is ever like "no worries, I'll go read the commits first, no need for documentation." (Don't get me started on "my code is so clear it doesn't need documentation" people...).
I think one big issue with all this is that costs are outsourced either to time or someone who isn't you, and this naively makes people believe that there is no cost (and sometimes fight to reject claims of cost. There is always a cost. There's a cost to everything). I wonder how much time and money would be saved if we recognized this. I just don't know how to motivate solving this, as it's non-obvious.
I've migrated to Wez already. I actually had issues with them too but wasn't as bad as Kovid. More like what you said "Not our problem, it's X's problem." (Brew devs love to do this too) Leaves a bad taste in my mouth but dismissal is better than dismissal + gaslighting + insulting.
Plus, Alacritty just hasn't been a great editor. (I wish foot would build a cross platform version[0]. But I'm not entitled enough to expect someone write code for me, though I might ask)
While I mostly agree, it looks like the fair amount of the article is about his attitude.
Something that was a bit surprising was the combative tone that Calibre's lead developer Kovid Goyal took in the comments on the bug. Rather than working with Donenfeld to see what the problems were, he dismissed most of the bugs as invalid. Even after Donenfeld tried to further point out the problems, Goyal was rather sarcastic in response:
You mean that a program designed to let an unprivileged user mount/unmount/eject anything he wants has a security flaw because it allows him to mount/unmount/eject anything he wants? I'm shocked.
This does not appear to have changed if you look at his responses to issues. I linked the tmux stuff in a different comment (same root).
Both skills and personality can chance a lot over a decade and I'm glad you're not quick to jump the gun. We need more people like that. But given brash comments over the past few years, it does not seem like this part has changed. He's been working on kitty for 8 years and has only accepted minor PRs and is dismissive of user issues.
Does WezTerm support an equivalent of iTerm's "hotkey window"?
For those unfamiliar, that's a window tied to a show/hide keybinding which when shown floats above all other windows, making a terminal instantly available everywhere - a feature I could live without, but don't care to. I'd love to switch for all of WezTerm's other features, but without that it's simply a nonstarter for me.
I don't have a keybinding to hide, but you could easily achieve that by inspecting the active window with `hs.window.focusedWindow()`/`hs.window.frontmostWindow()` and making the behavior conditional based on the application: https://www.hammerspoon.org/docs/hs.window.html#focusedWindo...
Note that this does only the “show/hide’ the window part;
The iTerm2 hotkey window, is a floating window, which for example also works in a space with another Fullscreen window/app opened (without moving to another space.)
I do it using https://gist.github.com/meowtochondria/8b99b8fbf364eec41ef66... on my Debian based machine running X11. I've bound this script to a key as a global shortcut using OS provided facilities. See the comment on gist if you have a different setup and want to adapt it to your needs.
Algo:
1. Find path to wezterm binary by looking at desktop file
2. Use pgrep to get pid of running binary from previous step.
3. If no window is running, launch desktop file using gio
4. If window is running, bring it to front using wmctrl
That's related to it, but the feature per se is more like a specially handled variety of iTerm's profiles. See https://iterm2.com/documentation-hotkey.html, section "Dedicated Hotkey Windows".
As I get older, overly opinionated and dismissive maintainers are perhaps the biggest red flag for avoiding a project now. They often have what looks like the best product out there, but once you get embedded in the product you get stuck in their choices and have nowhere to turn.
While I see nothing particularly egregious about Kitty's maintainer, other than being a bit of a dick, it's not really the job of a maintainer to be your pal.
Except, when I started using WezTerm at the start of this year... omg, this guy is absolutely fantastic.
I have read scores of his posts and he's struck the perfect tone in every single one. Love this guy, really, he's awesome.
Yeah: the kitty developer is definitely the sort who believes that he not only knows better than everyone else how to use a terminal, but that everyone else's opinions are fundamentally invalid. That his terminal fails to correctly render such stalwarts as the Linux "make menuconfig" UI and there are no settings to fix it as he doesn't believe in settings is, to me, telling. I then find reading his posts on issue trackers not just insulting, but even "activating" in a way that is really unhealthy, as it results in me feeling a need to "defend" some random bit of terminal usage with just as much vigor, lest he get away with making everyone else sound like THEY are crazy... it really isn't healthy. I can't know for sure--as we don't live in this reality--but I'd like to think that, even if he and I agreed on literally everything there is to do with terminals, that I'd still have the same mindset that I'd rather write my own terminal than ever use his.
Remember that this is the guy who said he would personally maintain python 2 because he didn't want to rewrite calibre for python 3 [0].
I try not to knock the guy, given that kitty and calibre in particular are amazing programs, but I still think you've gotta keep that in mind when engaging.
FWIW, his conduct on the MobileRead forums where he answers questions from newbies and enhancement requests are far more polite and charitable. His ire seems to be reserved for fellow programmers.
> he answers questions from newbies and enhancement requests are far more polite and charitable. His ire seems to be reserved for fellow programmers.
Some programmers (like myself) have little patience for people they consider should know better and are wasting their time. These same programmers are far more charitable to newbies because they know newbies are still learning.
> Remember that this is the guy who said he would personally maintain python 2 because he didn't want to rewrite calibre for python 3 [0].
I read his "I am perfectly capable of maintaining python 2 myself." as "I am perfectly capable of maintaining [calibre running on] python2 myself", which is completely different.
I'm sure some people might also find his answer quite terse and dismissive ("No, it doesn't."), but I read it as a simple statement of facts, using the same tone as the original bug report, which itself is quite terse and imperative "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
> Some programmers (like myself) have little patience for people they consider should know better and are wasting their time. These same programmers are far more charitable to newbies because they know newbies are still learning.
Some programmers are life-long learners and know a very different subset of things. It’s important to remember that just because something is obvious to you doesn’t make it right and doesn’t make it obvious to others.
Totally agree. Though, usually these programmers know how to properly ask a question, make a bug report and/or feature request.
They wouldn't, for example, just barge in an oss project with arguably low value statements like "Python 2 is retiring in thirty months. Calibre needs to convert to Python 3."
I am guessing you haven't interacted with the developer of kitty. It is astounding how needlessly rude he is. No matter our expertise, we all have areas of ignorance and it is precisely due to that ignorance that we may not have the language to "properly" frame our question. If we had that knowledge, we wouldn't be asking the question in the first place.
I have never seen a maintainer go so far above and beyond to condescend and insult people asking questions -- not making demands like your example. In my case, I asked a question about something that wasn't working as I expected in the github discussions and he repeatedly insulted my intellect (while simultaneously blaming another program when it was in fact a kitty misconfiguration that was causing my issue). He did eventually leave enough breadcrumbs that I was able to solve my problem but rarely have I had such a negative experience with asking an (IMO) not stupid question.
> I read his "I am perfectly capable of maintaining python 2 myself." as "I am perfectly capable of maintaining [calibre running on] python2 myself", which is completely different.
That doesn't make sense to me in context. Presumably he was already maintaining calibre on python2 at the time, so what additional information is he adding?
It seems more like he was saying "I am perfectly capable of maintaining my own fork of python2 for however-much-python-I-need to continue developing calibre." Which, granted, is not as grandiose as "I will become the maintainer for the abandoned python2 language for the internet at large to use", but it is still a rather tall order.
It depends upon what you mean by opinionated. There is software that expects users to behave in certain ways and there is software where the developer is quite firm about what they will and will not implement. I would say that calibre and kitty fit into the latter category. These applications offer a lot of features and are very configurable, yet they also don't try to be everything to everyone.
While I don't know why Goyal takes the approach he does, I would imagine that a lot of demands are placed on him simply because his software is so powerful (and, in the case of calibre, pretty much the only program in its domain that goes beyond serving basic needs).
How is the dev a jerk when they don't want to invest time into patching their app for the quirks of another app? Especially when kitty seems to have tmux-abilities out-of-the-box. I mean, you can like their solution or not, but calling them a jerk for not supporting your way?
You shouldn't believe things you read in hacker news comments. saurik is lying, probably because he once requested some feature that the kitty maintainer didnt like and refused with good reasons, which made saurik want to curl up into a ball and cry. To say kitty has no configuration options is the exact opposite of the truth. Proof: https://sw.kovidgoyal.net/kitty/conf/
I mean I might be "lying"... or I might be confusing him with the Gnome Terminal developers, with respect to that one specific tiny quote about "not liking settings".
(FWIW, the setting in question with respect to make menuconfig is "use bold as bright", where the kitty developer is on a vendetta to refuse the historical precedent. He is very adamant that he knows better than most everyone else on this point.)
Either way, I have never claimed to have talked to the kitty developer: I -- as well as multiple others on this thread -- are saying we've read how he handles arguing about terminals, and we don't like it.
Regardless, I do happen to be curled into a ball, and I do happen to look like I am crying... but it is merely because I am sick: I use xterm and I am very happy with the software and like the author.
OK so you are not lying, you are just wrong. Now that you have reduced the scope of your personal attack from he doesn't like settings to he doesn't agree with me about one thing, perhaps you should exercise your new found honesty a bit more and link to the issue where he refused to implement bold as bright and gave his reasons, which are perfectly sensible, namely that having that option means that the developers of terminal programs cannot rely on having a bold font face. Terminals are already limited to using only a single font size, you want to take away the ability to use bold faces as well. And you are trying to sell this as the kitty developer being unreasonable. Shame on you.
Look: my issue is that the kitty developer clearly thinks of himself as "God's gift to terminals". I pointed at one specific issue that I think is "telling" of an attitude of "I know better than everyone else", but I am not at all relying on that issue.
I just went through and started looking at recently closed issues on GitHub. I got through four before I found an example of what I think is the problem, and while this is a fairly benign one it is also clearly awkward enough that it shouldn't happen this often and is more than sufficient to clarify the complaint.
In this one, someone carefully points out an issue with a common script for emacs designed to implement the kitty-specific protocol (the one that kovid insisted everyone get on board with, as opposed to the prior art that already had traction, so now we have two competing ones; but that's my complaint, not the poster's).
Kovid then decides to pick a fight by being abrupt and a bit snarky in his response. Again: the issue was just technical and is good enough that I can probably debug the issue... I dream of getting bug reports like this, so this isn't the kind of response I would expect.
> I'm afraid I have zero interest in debugging emacs and kkp.el.
This is just downright mean-spirited. You can say something similar in a way that isn't grating in the same way, but Kovid prefers being grating, and clearly the person in the issue also took it this way and they get snarky back:
> If you aren't interested that's okay, of course.
> OTOH, I have zero interest in debugging Kitty. I'll just use Alacritty or iTerm :-)
Given Kovid's comment, I think this is in some sense a leveled response: Kovid is demonstrating he has little interest in being collaborative or helpful, even in an ecosystem that he created. I certainly don't act like that, even when people would use tools I actively disagreed with, I still would always help them debug it.
Kovid, of course, escalates this one further and leaves the thread in a pretty demoralizing place.
> Excellent! Don't let the door hit you on the way out.
Damn :/. That is what I am talking about. He isn't just grating in the way Linus was grating -- though Linus, to be clear, was also an asshole who, at some point, started to realize just how much of a problem he was being and is a lot better today -- and I also don't think he is just grating in the way that people who moralize (I am guilty of this one) do... he's just kind of mean, even when it makes no sense, and the result is that many issue threads with him get this "edge" about them where everyone is slowly escalating the burn until they just drop out of the thread entirely for their mental health.
(Part of me actually wants to now debug this specific issue, but I'd be doing it out of spite, and I do not want to be dragged into that. I only commented on this at all as I didn't want the person further upthread of me to feel alone in commenting on the problem with Kovid, and so I think it is reasonable that I get some of the flak here as I'm willing to bring the receipts.)
So, no: I simply don't think it is fair to say I am being dishonest, and the specific thing you quoted from me about him not liking settings is obviously not the point and wasn't something I delved into, as it didn't matter why: the issue was how... FWIW, in a thread where a bunch of people are all agreeing that Kovid turned them away from using kitty, maybe at least some of us have a point?
Let's discuss the parts you left out in your carefully constructed attempts at character assassination.
1) kitty has a template for issue reporting that the person that reported that issue didn't use, which means it isn't a carefully constructed report.
2) The issue is probably with kkp.el. I don't know about you, but I don't expect maintainers of open source projects to debug all issues in their own projects let alone unrelated ones. Kovid went out of his way to tell the OP exactly how to provide useful debug information. And he did so within a few minutes of the issue being opened.
3) The part you complain about is him saying he has zero interest in debugging kkp.el and emacs. Which is perfectly reasonable, again, why should he have an interest in it. He provided the OP with the means to give him information that he would be interested in debugging instead.
4) He then gets told that the OP would rather use some other terminal rather than provide the debug information he was asked for. Do you have any conception of how rude it is to go to some projects issue tracker and then state you are going to use a competitors product.
5) You tried again to insert an unjustified swipe at Kovid, with "the keyboard protocol he insists everyone get on board with". In reality that keyboard protocol is completely optional, an no one has to use it. The fact that everyone does actually use it, is testament to its being light years ahead of any of the alternatives and represents weeks of hard work on the part of Kovid to finally bring sanity to this corner of the terminal ecosystem. An effort he made for the good of the community. And an effort that has succeeded, since pretty much all modern/maintained terminal software support the protocol as it is clearly superior to the alternatives.
6) You were at best mistaken in making your claim that he doesnt like settings, but given you clearly have an agenda against someone who has done nothing to you other than provide the world free software, I think the default assumption is malice not incompetence on your part.
And yes by all means dont use kitty, I have a strong feeling that Kovid, who has been providing software used by millions of people for decades has reached a point in his life where he recognizes that some users cost way more than others. He is likely very happy that you and people like you give his work a miss.
A position I greatly sympathise with. People that report issues to open source projects need to remember they are asking for help, it behoves them to put in the maximum effort they can to reduce the burden of the free help they are NOT entitled too.
> where the kitty developer is on a vendetta to refuse the historical precedent
I mean, he's not wrong. Everyone else should update their shit to be proper so that he doesn't have to deal with all this legacy nonsense. It's just annoying as hell for people using it right now.
I recently moved from Kitty+Tmux to Tmux only setup. I think the maintainer has implemented most of the features in tmux like split panes, switching, changing layouts etc and is probably why says what he says.
I've been a long tmux user, but I've migrated to Kitty only setup. To make my muscle memory feel at home, I configured Kitty with nearly the same keybindings as tmux. Here is my setup https://blog.funcer.xyz/blog/kitty-terminal/
I appreciate his efforts, but tmux from my cold, dead hands. kitty is nice and fast, but tmux is in my blood (and on remote servers where kitty isn't).
I mostly like kitty but I’ve noticed that it takes a couple seconds to start up when I put my cpu down to 400Mhz. (Which might seem like an odd thing to do, but xterm handles it fine and, hey, why do we need billions of clock cycles to start up a terminal? That’s ridiculous).
400 is a bit extreme, it is as low as my clock will go. But I often go down to 1200 or 800.
I have an OLED screen and mostly use black background terminals, so I can get some pretty decent battery life out of it, especially at night when I dim the screen.
Dim/red shift/slow CPU is a nice low-distraction night time mode IMO.
Plus it is keeps my palms comfortable even if I accidentally run a computationally intensive code.
How is WezTerm compared to iTerm2, since you’ve used both?
I’ve tried Kitty a few times, since it has a few features I miss in iTerm2 (e.g. the “i3-gaps” aesthetics if you set the right flags, a plaintext config that is easier to sync, and its graphics and keyboard protocols have a wider ecosystem than iTerm2’s comparable features, and the “layout” feature).
But… I generally find that iTerm2 “just works” and requires little fiddling to get all the everyday stuff to work as I want, but I’ve been down many rabbit holes with my Kitty config. For now I’ve therefore stuck with iTerm2, but imagine that a well-configured Kitty might be nicer.
Basically it is how it presents itself as xterm-kitty and then how to make others recognize that. Installing terminfo on the remote is an option, lying and claim it to be xterm-256color is another (with caveats.)
As in other issues with kitty, the author is probably right. But for many people that they have many different kinds of remotes to log into where they don’t have control over, getting around with these issues is tedious.
Making kitty works is possible, and I learnt how to deal with these issues one by one, but hearing comments here on HN points me to wezterm and once I migrated I never looked back. For the simple stuffs wezterm gets out of the way. And there’s some interesting advanced stuffs to pick up, such as multiplexing with ssh: https://wezfurlong.org/wezterm/multiplexing.html?h=ssh#ssh-d...
> The focus of this study was not to analyse the prevalence of the occurrence of the median artery in relation to ethnicity, geographic origin or variations by sex, but to identify the global trends in its occurrence.
and thought "well that explains the astronomical precision of the p-value, they didn't take ethnicity into account!". You would expect to see variation prevalence vary by ethnicity, no big news here.
But no! Thinking about it more, that's exactly what is says on the tin: global ethnic populations changed in the last ~140 years, and with it, the prevalence of generic variations. Makes perfect sense ¯\_(ツ)_/¯
edit: I mean... assuming the causal link ofc. I'm assuming this makes more sense than some kind of evolutionary pressure that is selecting for forearm median arteries.
We need to retire the idea that evolution has a goal, or that evolutionary pressure explains everything. There are tons of things in the human body that are very suboptimal or are purely accidental, from the tons of "junk" DNA, our difficult birthing, the appendicitis, wisdom teeth, the way our knees fold, differences in earwax, etc, etc.
"Evolution" is just a (fairly tautological when you think about it) observation that "traits that manage to get passed on, subsist". It weeds out very bad traits, but the rest? It's just a giant lottery, not a great design with a teleological goal of "improving".
(And the human species has been short-lived so far, and may wipe out themselves without the "help" of a meteorite. In the same vein, cockroaches could be argued to be the pinnacle of evolution.)
While I agree with you, and also find the evolution = improvement views kind of annoying, I think you're also stating something that's accurate but perhaps misleading. Because when you say "good" or "bad" people are going to mistake that for what they personally think would be good or bad. When in reality good = makes you more likely to successfully reproduce, and bad = makes you less likely to successfully reproduce.
The best example of this is intelligence. In modern times, intelligence has become substantially inversely correlated with fertility. And as intelligence has high heritability, we are actively selecting against intelligence. And in fact we are already seeing generational declines (which had been previously been increasing for as long as IQ has been measured) in intelligence. [1] And this trend will continue until the point that intelligence and fertility once again become positively correlated. Nobody would ever say intelligence is a "bad" trait, but in evolutionary terms it has become one.
The study you linked to doesn't find heredity to be the driver of decline of IQ (which they pointedly reminded is not a measure of intelligence):
Regardless, we believe education, test-taking, and media exposure emerge as potential moderators for explaining the observed gains in three-dimensional rotation scores and declines or stagnation in matrix reasoning, letter and number series, verbal reasoning, and composite ability scores.
And did I say or even imply it was? Height is comparably heritable to adult IQ (and coincidentally is even strongly correlated with such) at around 0.8, but obviously somebody who is e.g. malnourished as a child will never reach their height (or intelligence) potential. And that's precisely why heritability is useful. It lets you create a ballpark estimate for the overall average influence of genetic vs contemporary environmental factors. So genetic factors would tend to explain about 80% of the differences in heights, with environmental factors taking up the remaining 20%. The heritability for factors without a genetic component is zero.
> There are tons of things in the human body that are very suboptimal or are purely accidental, from the tons of "junk" DNA, our difficult birthing, the appendicitis, wisdom teeth, the way our knees fold, differences in earwax, etc, etc.
Right, but evolution also can explain those; many of these are tradeoffs for things that do deliver benefits. Difficult, premature births are the cost of big brains, for instance.
> "Evolution" is just a (fairly tautological when you think about it) observation that "traits that manage to get passed on, subsist". It weeds out very bad traits, but the rest? It's just a giant lottery, not a great design with a teleological goal of "improving".
The tautological explanation is extremely powerful, because it means even a small variation that delivers a marginal but consistent advantage is going to be selected for. For instance, a person with dark skin can survive in Northern Europe, and a person with light skin can survive in sub-Saharan Africa, but the ideal skin tones for those regions that optimally trade off vitamin D production with protection against skin damage from the sun are probably pretty close to the ones typical to their indigenous populations.
The actual catch is that there’s a lot of path dependence and all changes are stepwise. You can’t just install a new trait or body part that’s been designed from scratch; it has to evolve from an earlier, similar thing. If you look at the bones of your hand, the bones of a bat’s wing, and the bones of the front paw of a dog, the bone structure is basically the same; it’s just by changing the proportions that you can get the structure of a flapping wing, a front foot, or a hand with an opposable thumb.
Evolution does have a goal - spreading genes. Of course when we say "it has a goal" that doesn't mean it intelligently plans how to get there. Nobody* thinks that.
I think what you probably meant to say is that evolution isn't a perfect optimiser.
It's also not optimizing for "maintain health in your 70s/80s/90s". A faster decline is probably evolutionarily advantageous to the small group of hunter-gatherers.
> The present study used an Australian sample of European origin. These results were comparable to those reported in black South Africans, their white counterparts and Malaysians of similar birth years; all these groups had a prevalence of approximately 30%
The draft spec[1] – soon to be published AFAICT – flips this on its head and says "no, the MCP server is an OAuth2 protected resource, just go and talk to this authorization server and I'll accept its tokens". The MCP server doesn't need to handle anything related to auth. That's much saner, and would recommend people build towards _that_ particular future in mind.
But also broadly speaking: I strongly believe the mental model needs to move to MCP servers are URLs. It should just be extra endpoints and controllers on top of your app. I don't want to `npm install mcp-your-app` or go through someone else's implementation, I want to hit `https://your.app.com/mcp` directly.
I guess it's fine having the separate infra for an MCP server used to connect to 3p services... but fingers crossed, your 3p services starts exposing MCP endpoints directly.
edit: Add URL, fix words
1. https://modelcontextprotocol.io/specification/draft/basic/au...