Most recently, KeyWe and modded Keep Talking with friends. Solo, still ol’ reliable slay the spire.

I have a plan to teach someone how to play schnapsen and crazyhouse chess tomorrow so that’s exciting.

I find there’s a lot less variety in my monster train runs. Most classes have a distinctly best strategy and the artifacts generally also funnel you towards that strategy. For example, I can’t remember the last time I played an Umbra run that didn’t set up a morsel engine behind a warden or alloyed construct - as far as I’m concerned, those are the same strategy, it doesn’t feel different. The only other build I think is viable is just “play Shadowsiege,” which rarely happens early enough to build for it.

Every class in STS has at least three viable archetypes and almost every run within those archetypes still feels different to me.

I almost exclusively play for A20 heart kills. I play all 4 classes but in a “whichever I feel like today” way. I tried rotating between the characters for a while and really didn’t enjoy playing silent or watcher while in the wrong mood for those classes.

My favorite deck in recent memory was probably a silent discard combo with Grand Finale as the only damage-dealing card in the deck. My favorite archetype in general is probably ice defect. A good all-you-can-eat ironclad run is great too.

I don’t think I agree that STS is especially well balanced - some regular hallway combats do irrationally more damage on average even to players much better than me (for example, floor one jaw worms or any act 3 darklings). In general, the game could be quite a bit harder on A20 and still be fun for players who want a challenge. It’s also weird to me that A1 makes the game easier compared to A0. Between the classes, there is a class which is clearly stronger than the others. However I also don’t think this is a bad thing. Imbalances create more opportunities for new experiences, and for different kinds of players to have different kinds of fun. And that certainly agrees with “infinite replayability.” I’m sure in 5 years’ time I will still be seeing interactions I’ve never seen before.

Second Shadow of the Colossus. The moments where you can just sit and look, coupled with the soundtrack, are some of the best in gaming history. Plus that bit of tension knowing what you’re about to get into…

Not only is tunic beautiful; the experience is amazing. It’s even better if you try to solve the main optional puzzle as you go.

Definitely agree that it’s one of the best.

I’m a computer scientist mainly but with a heavy focus/interest in computer architecture. My plan is to teach at a university at this point - but it seems to me like that would be a good place to create completely open standards technology from.^1Specifically because if the point isn’t to make money, there’s no reason to create walled gardens.

There’s certainly enough interest from people who want to be able to build their own systems. What would actually worry me isn’t the ability to make a new open standard or any of that. It’s that AMD64 is very hard to compete with in this space, because the processors are just faster, and there is so much x86 software that people who build PCs usually want access to.

AMD64’s performance is the result of years and years of optimizations and patenting new hardware techniques, followed by aggressively litigating people trying to compete. ARM performance is catching up but ARM prefers licensing their core IP over making their own systems, making it harder for them to break into the PC space even if they want to.

A new player would be in for a long, long time of unprofitable work just to compete with AMD64 - which most people are still happy with anyway.

^1 some others and I are actually working on some new ISA / open soft processors for it. However it is focused at an educational setting and unlikely to ever be used outside of embedded devices at most.

Neither spectre nor meltdown are specific to Intel. They may have been discovered on Intel hardware but the same attacks work against any system with branch prediction or load speculation. The security flaw is inherent to those techniques. We can mitigate them with better address space separation and address layout randomization. That is, we can prevent one process from reading another process’s data (which was possible with the original attacks), but we can’t guarantee a way to prevent malicious browser tab from reading data from a different tab (for example), even if they are both sandboxed. We also have some pretty cool ways to detect it using on-chip neural networks, which is a very fancy mitigation. Once it’s detected, a countermeasure can start screwing with the side channel to prevent leakage at a temporary performance cost.

Also, disabling hyper threading won’t cut your performance in half. If the programs that are running can keep the processor backend saturated, it wouldn’t make any noticeable difference. Most programs can only maintain about 70-80% saturation, and hyper threading fills in the gaps. However the result is that intensive, inherently parallelizable programs are actually penalized by hyper threading, which is why you occasionally see advice to disable it from people who are trying to squeeze performance out of gaming systems. For someone maintaining a server with critically sensitive data, that was probably good advice. For your home PC, which is low risk… you’re probably not worried about exposure in the first place. If you have a Linux computer you can probably even disable the default mitigations if you wanted.

These would be performance regressions, not correctness errors. Specifically, some false dependencies between instructions. The result of that is that some instructions which could be executed immediately may instead have to wait for a previous instruction to finish, even though they don’t actually need its result. In the worst case, this can be really bad for performance, but it doesn’t look like the affected instructions are too likely to be bottlenecks. I could definitely be wrong though; I’d want to see some actual data.

The pentium fdiv bug, on the other hand, was a correctness bug and was a catastrophic problem for some workloads.

I think the mitigations are acceptable, but for people who don’t want to worry about that, yes, it could put them off choosing AMD.

To reiterate what Tavis Ormandy (who found the bug) and other hardware engineers/enthusiasts say, getting these things right is very hard. Modern CPUs apply tons of tricks and techniques to go fast, and some of them are so beneficial that we accept that they lead to security risks (see Spectre and Hertzbleed for example). We can fully disable those features if needed, but the performance cost can be extreme. In this case, the cost is not so huge.

Plus, even if someone were to attack your home computer specifically, they’d have to know how to interpret the garbage data that they are reading. Sure, there might be an encryption key in there, but they’d have to know where (and when) to look*. Indeed, mitigations for attacks like spectre and hertzbleed typically include address space randomization, so that an attacker can’t know exactly where to look.

With Zenbleed, the problem is caused by something relatively simple, which amounts to a use-after-free of an internal processor resource. The recommended mitigation at the moment is to set a “chicken bit,” which makes the processor “chicken out” of the optimization that allocates that resource in the first place. I took a look at one of AMD’s manuals and I’d guess for most code, setting the chicken bit will have almost no impact. For some floating-point heavy code, it could potentially be major, but not catastrophic. I’m simplifying by ignoring the specifics but the concept is actually entirely accurate.

* If they are attacking a specific encrypted channel, they can just try every value they read, but this requires the attack to be targeted at you specifically. This is obviously more important for server maintainers than for someone buying a processor for their new gaming PC.

Invidious does use a YouTube API. FreeTube uses Invidious, so probably same story there. I don’t know about the others.

I recently had a back and forth with one of invidious’s developers. Judge for yourself.

Yeah i think you found the boss on accident if that’s the quest name you were seeing.

But so did I, so this can’t be that uncommon. I question the design of having some mid-game content in the same (surface) place as the end-game because it becomes unclear what you’re being pointed at. Put simply, tell me to walk towards the giant chasm; I’m jumping in.

I realized I wasn’t supposed to be there yet when I recognized a typical pre-boss pattern that Zelda games use a lot. Trying to avoid spoilers there.

Patrick’s parabox?

Shadow of the Colossus and Undertale.

Yeah, these are examples of the bad gameplay patterns I was referring to. One of them in particular (trying to be spoiler-light) provides you a ranged power… But you have to go to melee range to activate it. Whose idea was that?

Casually, I enjoyed it a lot. It felt like better BOTW, with much more new stuff to explore than I expected. My only gripes where the delay on quick menus (botw did not have that, and it feels awful) and I generally think the sage mechanic leads to bad play patterns. But overall, it’s amazing.

I’ve been involved in speedrunning both games. Versioning issues in TOTK are way worse. Movement tech in botw was a lot more interesting and varied, until windbombs were found anyway. The menu lag feels even worse while speedrunning. The stuff we’ve got for inside shrines is pretty cool, and there’s some very cool out-of-bounds stuff found already. So it’ll probably stay fresh for a while. I’m not sure if it’ll hold me for as long as botw did though.

To his credit, Ohanian hasn’t been involved with reddit for a while. He and u/spez sold the company years ago, then spez came back.

But that feels terrible if you want to follow them without stopping (or in the case of obstacles, are able to).

Even Ocarina of Time, in 1998, got this right. The Dampe race, which isn’t technically an escort, would feel weird if Dampe was too much faster or slower than you, because it would feel unfair. But not everyone moves as fast while playing - some people like rolling, which is a different speed from walking, etc. Also, he throws fireballs at you, and players who are less good at dodging them will end up being slower. So Dampe doesn’t “follow you,” (in fact, he spends most of the thing in front of you), but he has a rubber band effect. If you get too far behind, he slows down. If you get too far ahead, he speeds up. This does a good job of keeping him in view, which helps give the feeling that you’re going at an intended pace, whatever reasonable pace you take. If you’re too slow, you will fail, but… it pretty much requires standing still or getting hit by lots of fireballs.

In contrast, the Yunobo escort in BOTW feels terrible casually and even worse to speedrun. He’s faster than you walk, but much, MUCH slower than you run. And if you get too far ahead of him? He stops.

“Valid” and “disingenuous” mean very different things. How would you feel about editing that README point to be explicit that you use an unofficial undocumented YouTube API?

For the record, I don’t think “InnerTube” would be considered unofficial, legally. It’s authorized by YouTube, since they made and use it internally. That’s the definition of “official.” This is a small part of why I think the wording in the TOS makes the TOS apply to “InnerTube.” What makes you think that it doesn’t?

That makes Invidious’ readme (which claims no YouTube APIs at all) disingenuous at the very least.

More likely, you need a lawyer. I read that TOS, and I think it applies to any YouTube API endpoint, internal or otherwise. Best of luck, because I agree with Invidious’ goals…

Side note: a browser communicating with YouTube would be communicating with youtube. Not with com.google.android.youtube.api or whatever. What I’m seeing is that Invidious tries to act like the youtube service itself, which is very different from acting like a browser.

Edit: I’ve spent about 5 minutes over an hour looking for EU case law about this but haven’t been able to find anything except un-cited references to an exception for “producing interoperable devices.” Do you have sources? In the United States, at least, “clean room reverse engineering” has a pretty specific definition that follows four steps:

1. A (team of) engineers reverse-engineers an existing product, in this case, the YouTube internal API.
2. Those engineers write a specification of the product’s (outwardly-visible) behavior.
3. A lawyer reviews that specification to ensure that it does not contain anything infringing on any copyrights relevant to the product.
4. A separate (team of) engineers re-implement the product according to the specification.

I don’t think what you’re doing meets that definition. You achieved step 1, and possibly step 2, and then didn’t attempt the others. You reverse engineered something for the purpose of using it - but you haven’t actually reimplemented it, which is the “clean room” part of “clean room reverse engineering.” Re-implementing it would presumably require building your own server for actually hosting videos on Invidious instances.

There’s quite a history of this term in the US, going back to even before Intel vs. NEC, when it was very much in the public eye. NEC had designed a microprocessor with the same instruction set as the popular Intel 8080 [same instruction set = interoperability]. Internally, both devices use “microcode” to drive their execution. In the analogy, that microcode is the “InnerTube” API. NEC’s “V20” device was quite different from the 8080, and needed its own microcode. Intel claimed that NEC violated Intel’s copyright by basing NEC’s microcode on the 8080’s. As part of arguing this, NEC rewrote their microcode from scratch following proper cleanroom procedure, and the decision in the case partly relies on this to decide that NEC is in the clear. Had NEC simply injected the 8080 microcode into their NEC-V20 device directly, the case would probably have gone very differently. It would also be a very different case, because the NEC-V20 device would look completely different.

You didn’t re-implement InnerTube. You injected InnerTube into your own service. Had you re-implemented InnerTube as part of Invidious, Invidious would look completely different.

Anyway, all that aside, even if what you’re doing did meet the conditions of clean-room reverse engineering, I don’t think it would fall under the (again, un-cited, so maybe we’re talking about different things) interoperability exception in the EU. You’re not producing a device/service that needs to be interoperable with other devices/services. You’re producing a service with an explicit goal of operating differently.

To be clear, IANAL, but your reasoning seems shaky.

It’s certainly possible to scrape data from interactions with a site directly, without using its API. This is even legal - there were no gymnastics in my response there. However, that decision has since been remanded, then re-affirmed, then challenged, and then LinkedIn obtained an injuction against HiQ which the two of them are still fighting over. So it could get properly overturned.

I definitely thought it seemed like it would be difficult to do this to offer a youtube frontend, but plausible enough that I didn’t look into it. Thank you for this. I’m looking more closely now :)

If they are using undocumented internal APIs, do YouTube’s API TOS apply to those? I checked the text of the TOS and it seems to me like it should apply; they say “The YouTube API services … made available by YouTube including …”. That seems broad enough to me to cover internal APIs as well, if their endpoints are accessible, but IANAL.

Also, the open response to the C&D seems to throw shade at the TOS saying “The “YouTube API Services” means (i) the YouTube API services” but ignores that this is immediately followed by parenthetical examples and qualifiers. The TOS is defining the term so that it doesn’t have to repeatedly add the qualifiers. Nothing weird about that. That’s uh… pretty bad-faith arguing, if I’m interpreting it correctly.

Edit: assuming you refer to the same reverse engineering points that they made above… yeah.