{"id":136,"date":"2007-07-29T10:01:48","date_gmt":"2007-07-29T17:01:48","guid":{"rendered":"http:\/\/ryanorser.com\/?p=136"},"modified":"2007-07-29T10:01:48","modified_gmt":"2007-07-29T17:01:48","slug":"20070729-it-on-slashdot-dont-overlook-efficient-cc-cmd-line-processing","status":"publish","type":"post","link":"https:\/\/ryanorser.com\/index.php\/2007\/07\/29\/20070729-it-on-slashdot-dont-overlook-efficient-cc-cmd-line-processing\/","title":{"rendered":"2007\/07\/29 IT on Slashdot: Don\u2019t Overlook Efficient C\/C++ Cmd Line Processing"},"content":{"rendered":"

here is a story on Slashdot:<\/a><\/p>\n

\u00a0 \t\t\tFiredog writes “There’s been a lot of recent debate<\/a> over why Linus Torvalds chose the new CFS process scheduler written by Ingo Molnar over the SD process scheduler written by Con Kolivas, ranging from discussing the quality of the code to favoritism and outright conspiracy theories. KernelTrap is now reporting Linus Torvalds’ official stance as to why he chose<\/a> the code that he did. ‘People who think SD was “perfect” were simply ignoring reality,’ Linus is quoted as saying. He goes on to explain that he selected the Completely Fair Scheduler because it had a maintainer who has proven himself willing and able to address problems as they are discovered. In the end, the relevance to normal Linux users is twofold: one is the question as to whether or not the Linux development model is working, and the other is the question as to whether the recently released 2.6.23 kernel will deliver an improved desktop experience.”<\/em><\/p><\/blockquote>\n

Here is the story on the Kernel Trap:<\/a><\/p>\n

\n

Linux: Linus On CFS vs SD<\/h2>\n

July 27, 2007 – 8:10pm<\/p>\n

Submitted by Jeremy<\/a> on July 27, 2007 – 8:10pm.<\/p>\n

“People who think SD was ‘perfect’ were simply ignoring reality,<\/em>” Linus Torvalds began in a succinct explanation as to why he chose the CFS scheduler written by Ingo Molnar instead of the SD scheduler written by Con Kolivas. He continued, “sadly, that seemed to include Con too, which was one of the main reasons that I never [entertained] the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them.<\/em>” He went on to stress the importance of working toward a solution that is good for everyone, “that was where the SD patches fell down. They didn’t have a maintainer that I could trust to actually care about any other issues than his own.<\/em>” He then offered some praise to Ingo, “as a long-term maintainer, trust me, I know what matters. And a person who can actually be bothered to follow up on problem reports is a *hell* of a lot more important than one who just argues with reporters.<\/em>” Linus went on to note a comparison between the two schedulers:<\/p>\n

“I realize that this comes as a shock to some of the SD people, but I’m told that there was a university group that did some double-blind testing of the different schedulers – old, SD and CFS – and that everybody agreed that both SD and CFS were better than the old, but that there was no significant difference between SD and CFS.”<\/p><\/blockquote>\n

Con Kolivas maintained the -ck<\/a> Linux kernel patchset which aimed at improving the desktop experience since 2002, originally for the 2.4 kernel. Shortly after the decision to merge the CFS scheduler instead of his SD scheduler, and without an official response about merging his swap prefetch patch<\/a>, he announced his decision<\/a> to stop working on the Linux kernel. More information about his contributions and recent decision can be found in this interview on apcmag.com<\/a>.<\/p>\n

Ingo Molnar wrote the original CFS scheduler<\/a> within a 62 hour window of time starting on April 11’th, 2007. Early reports<\/a> on the CFS scheduler suggested it was an improvement over the old scheduler, but perhaps not over the SD scheduler. Ingo determinedly followed up on all bug and regression reports, rapidly improving the scheduler and addressing all known issues. It was merged<\/a> into the 2.6.23 kernel on July 9’th, three months after it was written.<\/p>\n

\n

From:\tKasper Sandberg<\/strong> [email blocked]
\nTo:\tLinus Torvalds [email blocked]
\nSubject: Re: Linus 2.6.23-rc1
\nDate:\tSat, 28 Jul 2007 04:04:39 +0200<\/p>\n

(sorry for repost, but there seemed to have been some troubles..)<\/p>\n

On Sun, 2007-07-22 at 14:04 -0700, Linus Torvalds wrote:
\n> Ok, right on time, two weeks afetr 2.6.22, there’s a 2.6.23-rc1 out there.
\n>
\n> And it has a *ton* of changes as usual for the merge window, way too much
\n> for me to be able to post even just the shortlog or diffstat on the
\n> mailing list (but I had many people who wanted to full logs to stay
\n> around, so you’ll continue to see those being uploaded to kernel.org).
\n>
\n> Lots of architecture updates (for just about all of them – x86[-64], arm,
\n> alpha, mips, ia64, powerpc, s390, sh, sparc, um..), lots of driver updates
\n> (again, all over – usb, net, dvb, ide, sata, scsi, isdn, infiniband,
\n> firewire, i2c, you name it).
\n>
\n> Filesystems, VM, networking, ACPI, it’s all there. And virtualization all
\n> over the place (kvm, lguest, Xen).
\n>
\n> Notable new things might be the merge of the cfs scheduler, and the UIO
\n> driver infrastructure might interest some people.
\n>
\nIm still not so keen about this, Ingo never did get CFS to match SD in
\nsmoothness for 3d applications, where my test subjects are quake(s),
\nworld of warcraft via wine, unreal tournament 2004. And this is despite
\nmany patches he sent me to try and tweak it. As far as im concerned, i
\nmay be forced to unofficially maintain SD for my own systems(allthough
\nlots in the gaming community is bound to be interrested, as it does make
\ngames lots better)<\/p>\n

<snip><\/p>\n

From:\tLinus Torvalds<\/strong> [email blocked]
\nTo:\tKasper Sandberg [email blocked]
\nSubject: Re: Linus 2.6.23-rc1
\nDate:\tFri, 27 Jul 2007 19:35:58 -0700 (PDT)<\/p>\n

On Sat, 28 Jul 2007, Kasper Sandberg wrote:
\n>
\n> Im still not so keen about this, Ingo never did get CFS to match SD in
\n> smoothness for 3d applications, where my test subjects are quake(s),
\n> world of warcraft via wine, unreal tournament 2004. And this is despite
\n> many patches he sent me to try and tweak it.<\/p>\n

You realize that different people get different behaviour, don’t you?
\nMaybe not.<\/p>\n

People who think SD was “perfect” were simply ignoring reality. Sadly,
\nthat seemed to include Con too, which was one of the main reasons that I
\nnever ended entertaining the notion of merging SD for very long at all:
\nCon ended up arguing against people who reported problems, rather than
\ntrying to work with them.<\/p>\n

Andrew also reported an oops in the scheduler when SD was merged into -mm,
\nso there were other issues.<\/p>\n

> As far as im concerned, i may be forced to unofficially maintain SD for
\n> my own systems(allthough lots in the gaming community is bound to be
\n> interrested, as it does make games lots better)<\/p>\n

You know what? You can do whatever you want to. That’s kind of the point
\nof open source. Keep people honest by having alternatives.<\/p>\n

But the the thing is, if you want to do a good job of doing that, here’s a
\nbig hint: instead of keeping to your isolated world, instead of just
\ntalking about your own machine and ignoring other peoples machines and
\nissues and instead of just denying that problems may exist, and instead of
\nattacking people who report problems, how about working with them?<\/p>\n

That was where the SD patches fell down. They didn’t have a maintainer
\nthat I could trust to actually care about any other issues than his own.<\/p>\n

So here’s a hint: if you think that your particular graphics card setup is
\nthe only one that matters, it’s not going to be very interesting for
\nanybody else.<\/p>\n

[ I realize that this comes as a shock to some of the SD people, but I’m
\ntold that there was a university group that did some double-blind
\ntesting of the different schedulers – old, SD and CFS – and that
\neverybody agreed that both SD and CFS were better than the old, but that
\nthere was no significant difference between SD and CFS. You can try
\nasking Thomas Gleixner for more details. ]<\/p>\n

I’m happy that SD was perfect for you. It wasn’t for others, and it had
\nnobody who was even interested in trying to solve those issues.<\/p>\n

As a long-term maintainer, trust me, I know what matters. And a person who
\ncan actually be bothered to follow up on problem reports is a *hell* of a
\nlot more important than one who just argues with reporters.<\/p>\n

Linus<\/p>\n

From:\tGrzegorz Kulewski<\/strong> [email blocked]
\nTo:\tLinus Torvalds [email blocked]
\nSubject: Re: [ck] Re: Linus 2.6.23-rc1
\nDate:\tSat, 28 Jul 2007 09:09:06 +0200 (CEST)<\/p>\n

On Fri, 27 Jul 2007, Linus Torvalds wrote:
\n> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
\n>>
\n>> Im still not so keen about this, Ingo never did get CFS to match SD in
\n>> smoothness for 3d applications, where my test subjects are quake(s),
\n>> world of warcraft via wine, unreal tournament 2004. And this is despite
\n>> many patches he sent me to try and tweak it.
\n>
\n> You realize that different people get different behaviour, don’t you?
\n> Maybe not.
\n>
\n> People who think SD was “perfect” were simply ignoring reality. Sadly,
\n> that seemed to include Con too, which was one of the main reasons that I
\n> never ended entertaining the notion of merging SD for very long at all:
\n> Con ended up arguing against people who reported problems, rather than
\n> trying to work with them.<\/p>\n

I don’t really want to keep all that -ck flamewar going but this sum-up is
\na little strange for me:<\/p>\n

If Con was thinking SD was “perfect” why he released 30+ versions of it?
\nAnd who knows how many versions of his previous scheduler?<\/p>\n

Besides Con always tried to help people and improve his code if some bugs
\nor problems were reported. Archives of this list prove that. I reported
\nseveral problems (on list and privately) and all were fixed very fast and
\nwith very kind responses. I had run -ck for months and years and it was
\nalways very stable (I remember one broken “stable” version).<\/p>\n

I don’t know what exactly are you refering to when you say about those
\nunaddressed reports but maybe it depends on who was asking, how and to do
\nwhat (for example – purely theoretical one, I don’t remember exact emails
\nyou refering to so I am not saying it happened – stating at the beginning
\nthat the whole design is unacceptable and interactivity hacks are a
\nmust-have won’t make a friend from any maintainer and for sure lowers his
\ndesire to get anything fixed for that guy). Or maybe Con had some bad day
\nor was depressed. Happens. But I really don’t remember Con ignoring too
\nmany valuable user reports in last 3 years…<\/p>\n

And no – I am not thinking that SD was “perfect”. Nothing is perfect,
\nespecially not software. But it was based on months and years of Con’s
\nexperience with desktop and gaming workloads and extensively tested in
\nsimilar uses by _many_ others. In nearly all possible desktop
\nconfigurations, with most games and all video drivers. This is why it was
\nperfectly designed and tuned for such workloads while still being general
\nenough and without any ugly hacks. And because of these tests and Con’s
\nbelieve that the desktop is very (most?) important all bugs and problems
\nin this area were probably killed long ago. I think even design was
\nchanged and tuned a little at the early stages to help solve such
\ninteractivity\/dekstop\/gaming problems.<\/p>\n

So it does not surprise me that CFS is worse in such workloads (at least
\nfor some people) because I strongly suspect that the number of people who
\nplayed games with current version of CFS is limited to about 5, maybe 10.
\nAnd I also suspect that you (and Ingo) will get many regression reports
\nwhen 2.6.23 is released (and months later too… or maybe you won’t
\nbecause users will be to “scared” to report such hard to mensure and
\nreproduce “unimportant” bugs). Hopefully such problems when reported will
\nbe addressed as soon as they can. And hopefully they will be easy enough
\nto solve without rewriting or redesigning CFS and causing that way even
\nmore regressions in other areas. If not people will probably be patching
\nO(1) scheduler back privately…<\/p>\n

Thanks,<\/p>\n

Grzegorz Kulewski<\/p>\n

From:\tLinus Torvalds<\/strong> [email blocked]
\nSubject: Re: [ck] Re: Linus 2.6.23-rc1
\nDate:\tSat, 28 Jul 2007 10:12:32 -0700 (PDT)<\/p>\n

On Sat, 28 Jul 2007, Jonathan Jessup wrote:
\n>
\n> Linus, there is a complaint about the Linux kernel, this complaint is that
\n> the Linux kernel isn’t giving priorities to desktop interactivity and
\n> experience. The response on osnews.com etc have shown that there is public
\n> demand for it too.<\/p>\n

No, the response on osnews.com only shows that there are a lot of armchair
\ncomplainers around.<\/p>\n

People are suggesting that you’d have a separate “desktop kernel”. That’s
\ninsane. It also shows total ignorance of maintainership, and reality. And
\nI bet most of the people there haven’t tested _either_ scheduler, they
\njust like making statements.<\/p>\n

The fact is, I’ve _always_ considered the desktop to be the most important
\npart. And I suspect that that actually is true for most kernel developers,
\nbecause quite frankly, that’s what 99% of them ends up using. If a kernel
\ndeveloper uses Windows for his day-to-day work, I sure as hell wouldn’t
\nwant to have him developing Linux. That has nothing to do with anything
\nanti-windows: but the whole “eat your own dogfood” is a very fundamental
\nthing, and somebody who doesn’t do that shouldn’t be allowed to be even
\n_close_ to a compiler!<\/p>\n

So the whole argument about how kernel developers think that the desktop
\nisn’t important is totally made-up crap by Con, and then parrotted by
\nosnews and other places.<\/p>\n

The fact is, most kernel developers realize that Linux is used in
\ndifferent places, on different machines, and with different loads. You
\ncannot make _everybody_ happy, but you can try to do as good a job as
\npossible. And doing “as good a job as possible” very much includes not
\nfocusing on any particular load.<\/p>\n

And btw, “the desktop” isn’t actually one single load. It’s in fact a lot
\nof very different loads, and different people want different things. What
\nmakes the desktop so interesting is in fact that it shows more varied
\nusage than any other niche – and no, 3D gaming isn’t “it”.<\/p>\n

> Maybe once or twice Con couldn’t help or fix an issue but isn’t that what
\n> open source software is all about anyway?<\/p>\n

That’s not the issue.<\/p>\n

Con wass fixated on one thing, and one thing only, and wasn’t interested
\nin anythign else – and attacked people who complained. Compare that to
\nIngo, who saw that what Con’s scheduler did was good, and tried to solve
\nthe problems of people who complained.<\/p>\n

The ck mailing list is\/was also apparently filled with people who all had
\nthe same issues, which is seriously the *wrong* thing to do. It means that
\nany “consensus” coming out of that kind of private list is totally
\nworthless, because the people you ask are already in agreement – you have
\na so-called “selection bias”, and they just reinforce their own opinions.<\/p>\n

Which is why I don’t trust mailing lists with a narrow topic. They are
\n_useless_. If you cannot get many different people from _different_ areas
\nto test your patches, and cannot see the big picture, the end result won’t
\nlikely be very interesting to others, will it?<\/p>\n

The fact is, _any_ scheduler is going to have issues. I will bet you
\nalmost any amount of money that people are going to complain about Ingo’s
\nscheduler when 2.6.23 is released. That’s not the issue: the issue is that
\nthe exact same thing would have happened with CK too.<\/p>\n

So if you are going to have issues with the scheduler, which one do you
\npick: the one where the maintainer has shown that he can maintain
\nschedulers for years, can can address problems from _different_ areas of
\nlife? Or the one where the maintainer argues against people who report
\nproblems, and is fixated on one single load?<\/p>\n

That’s really what it boils down to. I was actually planning to merge CK
\nfor a while. The _code_ didn’t faze me.<\/p>\n

Linus<\/p>\n

\n

From:\tKasper Sandberg<\/strong> [email blocked]
\nTo:\tLinus Torvalds [email blocked]
\nSubject: Re: Linus 2.6.23-rc1
\nDate:\tSat, 28 Jul 2007 11:44:08 +0200<\/p>\n

On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote:
\n>
\n> On Sat, 28 Jul 2007, Kasper Sandberg wrote:
\n> >
\n> > Im still not so keen about this, Ingo never did get CFS to match SD in
\n> > smoothness for 3d applications, where my test subjects are quake(s),
\n> > world of warcraft via wine, unreal tournament 2004. And this is despite
\n> > many patches he sent me to try and tweak it.
\n>
\n> You realize that different people get different behaviour, don’t you?
\n> Maybe not.<\/p>\n

Sure.<\/p>\n

>
\n> People who think SD was “perfect” were simply ignoring reality. Sadly,
\n> that seemed to include Con too, which was one of the main reasons that I
\n> never ended entertaining the notion of merging SD for very long at all:
\n> Con ended up arguing against people who reported problems, rather than
\n> trying to work with them.<\/p>\n

Im not saying its perfect, not at all, neither am i saying CFS is bad,
\nsurely CFS is much better than the old one, and i agree with what that
\nuniversity test you mentioned on kerneltrap says, that CFS and SD is
\nbasically impossible to feel difference in, EXCEPT for 3d under load,
\nwhere CFS simply can not compete with SD, theres no but, this is how it
\nhas acted on every system ive tested, and YES, others reported it too,
\nwhether you choose to see it or not. and others people who run games on
\nlinux tells me the exact same thing, and i have had quite a few people
\ntry this.<\/p>\n

>
\n> Andrew also reported an oops in the scheduler when SD was merged into -mm,
\n> so there were other issues.<\/p>\n

And whats the point here? If you are trying to pull the old “Con just
\nruns away”, forget it, its a certainty that he would have put the
\nrequired time into fixing whatever issues arise.<\/p>\n

>
\n> > As far as im concerned, i may be forced to unofficially maintain SD for
\n> > my own systems(allthough lots in the gaming community is bound to be
\n> > interrested, as it does make games lots better)
\n>
\n> You know what? You can do whatever you want to. That’s kind of the point
\n> of open source. Keep people honest by having alternatives.<\/p>\n

True that<\/p>\n

>
\n> But the the thing is, if you want to do a good job of doing that, here’s a
\n> big hint: instead of keeping to your isolated world, instead of just
\n> talking about your own machine and ignoring other peoples machines and
\nFirst off, i’ve personally run tests on many more machines than my own,
\ni’ve had lots of people try on their machines, and i’ve seen totally
\nunrelated posts to lkml, plus i’ve seen the experiences people are
\nwriting about on IRC. Frankly, im not just thinking of myself.<\/p>\n

> issues and instead of just denying that problems may exist, and instead of
\n> attacking people who report problems, how about working with them?<\/p>\n

As i recall, there was only 1 persons reports that were attacked, and
\nthat was because the person repeatedly reported the EXPECTED behavior as
\nbroken, simply because it was FAIRLY allocating the cpu time, and this
\ndid not meet with the dudes expectations. And it was after multiple
\nmails he was “attacked”<\/p>\n

>
\n> That was where the SD patches fell down. They didn’t have a maintainer
\n> that I could trust to actually care about any other issues than his own.<\/p>\n

You may not have been able to trust Con, but thats because you havent
\ntaken the time to actually really see whats been going on, if you just
\nread the threads for SD you’d realize that he was more than willing to
\nmaintain it, after all, why do you think he wrote and submitted it? you
\nthink he just wrote it to piss you off by having it merged and leave?<\/p>\n

>
\n> So here’s a hint: if you think that your particular graphics card setup is
\n> the only one that matters, it’s not going to be very interesting for
\n> anybody else.<\/p>\n

as explained earlier, its not just my particular setup, but actually
\nthat of alot of people, with lots of different hardware.<\/p>\n

>
\n>
\n> [ I realize that this comes as a shock to some of the SD people, but I’m
\n> told that there was a university group that did some double-blind
\n> testing of the different schedulers – old, SD and CFS – and that
\n> everybody agreed that both SD and CFS were better than the old, but that
\n> there was no significant difference between SD and CFS. You can try
\n> asking Thomas Gleixner for more details. ]
\n>
\n> I’m happy that SD was perfect for you. It wasn’t for others, and it had
\n> nobody who was even interested in trying to solve those issues.
\n>
\n> As a long-term maintainer, trust me, I know what matters. And a person who
\n> can actually be bothered to follow up on problem reports is a *hell* of a
\n> lot more important than one who just argues with reporters.<\/p>\n

Okay, i wasnt going to ask, but ill do it anyway, did you even read the
\nthreads about SD? Con was extremely polite to everyone, and he did work
\nwith a multitude of people, you seem to be totally deadlocked into the
\nONE incident with a person that was unhappy with SD, simply for being a
\nfair scheduler.<\/p>\n

From:\tLinus Torvalds<\/strong> [email blocked]
\nTo:\tKasper Sandberg [email blocked]
\nSubject: Re: Linus 2.6.23-rc1
\nDate:\tSat, 28 Jul 2007 10:50:48 -0700 (PDT)<\/p>\n

On Sat, 28 Jul 2007, Kasper Sandberg wrote:
\n>
\n> First off, i’ve personally run tests on many more machines than my own,
\n> i’ve had lots of people try on their machines, and i’ve seen totally
\n> unrelated posts to lkml, plus i’ve seen the experiences people are
\n> writing about on IRC. Frankly, im not just thinking of myself.<\/p>\n

Ok, good. Has anybody tried to figure out why 3D games seem to be such a
\nspecial case?<\/p>\n

I know Ingo looked at it, and seemed to think that he found and fixed
\nsomething. But it sounds like it’s worth a lot more discussion.<\/p>\n

> Okay, i wasnt going to ask, but ill do it anyway, did you even read the
\n> threads about SD?<\/p>\n

I don’t _ever_ go on specialty mailing lists. I don’t read -mm, and I
\ndon’t read the -fs mailing lists. I don’t think they are interesting.<\/p>\n

And I tried to explain why: people who concentrate on one thing tend to
\nbecome this self-selecting group that never looks at anything else, and
\nthen rejects outside input from people who hadn’t become part of the “mind
\nmeld”.<\/p>\n

That’s what I think I saw – I saw the reactions from where external people
\nwere talking and cc’ing me.<\/p>\n

And yes, it’s quite possible that I also got a very one-sided picture of
\nit. I’m not disputing that. Con was also ill for a rather critical period,
\nwhich was certainly not helping it all.<\/p>\n

> Con was extremely polite to everyone, and he did work
\n> with a multitude of people, you seem to be totally deadlocked into the
\n> ONE incident with a person that was unhappy with SD, simply for being a
\n> fair scheduler.<\/p>\n

Hey, maybe that one incident just ended up being a rather big portion of
\nwhat I saw. Too bad. That said, the end result (Con’s public gripes about
\nother kernel developers) mostly reinforced my opinion that I did the right
\nchoice.<\/p>\n

But maybe you can show a better side of it all. I don’t think _any_
\nscheduler is perfect, and almost all of the time, the RightAnswer(tm) ends
\nup being not “one or the other”, but “somewhere in between”.<\/p>\n

It’s not like we’ve come to the end of the road: the baseline has just
\nimproved. If you guys can show that SD actually is better at some loads,
\nwithout penalizing others, we can (and will) revisit this issue.<\/p>\n

So what you should take away from this is that: from what I saw over the
\nlast couple of months, it really wasn’t much of a decision. The difference
\nin how Ingo and Con reacted to peoples reports was pretty stark. And no, I
\nhaven’t followed the ck mailing list, and so yes, I obviously did get just
\na part of the picture, but the part I got was pretty damn unambiguous.<\/p>\n

But at the same time, no technical decision is ever written in stone. It’s
\nall a balancing act. I’ve replaced the scheduler before, I’m 100% sure
\nwe’ll replace it again. Schedulers are actually not at all that important
\nin the end: they are a very very small detail in the kernel.<\/p>\n

\t\t\t\tLinus<\/p><\/blockquote>\n

That is all for today!<\/p>\n

Ryan<\/p>\n","protected":false},"excerpt":{"rendered":"

here is a story on Slashdot: \u00a0 Firedog writes “There’s been a lot of recent debate over why Linus Torvalds chose the new CFS process scheduler written by Ingo Molnar over the SD process scheduler written by Con Kolivas, ranging from discussing the quality of the code to favoritism and outright conspiracy theories. KernelTrap is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[],"_links":{"self":[{"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/posts\/136"}],"collection":[{"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/comments?post=136"}],"version-history":[{"count":0,"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/posts\/136\/revisions"}],"wp:attachment":[{"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/media?parent=136"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/categories?post=136"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ryanorser.com\/index.php\/wp-json\/wp\/v2\/tags?post=136"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}