Programmer, graduate student, and gamer. I’m also learning French and love any opportunity to practice :)

  • 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 1st, 2023

help-circle

  • 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.



  • I’ve used it to fix regressions, most recently in a register allocator for a compiler. There’s pretty much no chance I would’ve found that particular bug otherwise; it was caused by an innocuous change (one of those “this shouldn’t matter” things) clashing badly with an incorrect assumption baked into a completely different part of the allocator.

    I had seen the same effect from an unrelated bug on a different program. When I added a new test and saw the same effect, I had a “didn’t I fix this already?” moment. When I saw that the previous fix was still there, I checked if an older version of the allocator exhibited the same bug on the new test, and it did not. Bisecting found the offending change relatively quickly and further conventional testing exposed the incorrect assumption.


  • Learning how to program in any language will make it easier to pick up any other language, because the main burden for a beginner is how to think programmatically. However once you’re enough past that wall, being an expert on one language will mostly only help pick up languages that are similar. So if you knew C++, you could pick up the syntax and probably most of the semantics of the others very quickly, because they are similar in that regard. But you’d still probably struggle to actually program in C, because C is lower level (has way fewer features) than C++.

    Technically speaking, C is a subset of C++. But that doesn’t mean being a good C++ programmer automatically makes you a good C programmer.

    C# is similar to the other two in syntax as well, but it’s much more like Java than either of them.


  • If you want to make simpler games, you could start with scratch or stencyl. These tools aren’t really programming languages per se but they let you build programs out of blocks that are much easier to visualize and play around with. There’s some research that suggests they are good entry languages and some research that suggests they aren’t, so ymmv. I’ve used both, but I knew how to program already.

    For the record you shouldn’t let “usually made with” drive your decisions. Java is still popular for some games. Slay the spire, a very popular deck building game, was written in Java, which is a decently popular choice if you want to support modding. But C++ and C# are more popular simply because that’s what you use if you’re using engines like unity or unreal.

    side note: C, C++, and C# are all different languages.


  • I’m a bit confused by your comment. They say in their post that they will reevaluate when Lemmy’s mod tools improve. More granular control over federation could help too. It’s a temporary measure.

    It’s not like they’re taking extreme action because they want to cause schisms. “They will defederate with everyone” only seems to apply if every other huge instance also has high numbers of trolls. Maybe not so unlikely, but mod tools on Lemmy will hopefully improve by then. Note: you sign up for beehaw’s rules when you choose to interact on beehaw, not when you sign up to beehaw. The issue they are dealing with here is that they have had to disproportionately moderate users interacting on beehaw coming from those instances.

    And at the end of the day, if beehaw becomes too isolated, it takes like 5 clicks to open a different instance in my browser and sign up there instead.


  • Lemmy specifically hasn’t implemented less harsh measures yet. This is a stop-gap action to cut off a trolling problem at its source. The beehaw admins say they will reevaluate when less drastic tools are available, e.g. allow beehaw users to interact with lemmy.world but not the other way around.

    I’m not sure I 100% agree, personally, but beehaw’s ethos is “be(e) nice” and if trolls are trolling, it can make it very hard for some people to open up and contribute. So I see where it’s coming from.





  • 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.



  • I’ll admit I hadn’t seen that, and that I was just echoing what TheFrenchGhosty said. That sure does look like official API access. They also seem to make calls through that wrapper to access comments and plenty of other things, so it’s not just sitting there unused.

    Thankfully, TheFrenchGhosty is on the Fediverse, so let’s ask them: @TheFrenchGhosty@lemmy.pussthecat.org @TheFrenchGhosty@libretooth.gr (not sure which one of these to use) How is this not using an official YouTube API?

    The README and the refute of YouTube’s C&D letter both claim that Invidious doesn’t use YouTube’s APIs at all - not merely that the response creation/interpretation was reverse-engineered. Obviously, the TOS applies to the fact that you interact with the API, not whether you access it manually or with the help of some code pre-prepared by Google. Yet it seems that other people have vetted you and not raised this issue. So I’m assuming we’re simply misunderstanding here, and hoping you can clear it up.




  • Make sure it actually overwrote all your comments. PowerDeleteSuite doesn’t respect the edit rate limit. I used a fork which runs much slower but respects the limit.

    Also, it’s a good idea to wait several days between the editing and deleting your account. Many users on reddit were suggesting that reddit holds on to pre-edit text for a while. Obviously archives hold onto it forever, but if your goal is to deny your content to reddit, that’s orthogonal.



  • Well sovereign citizen argument is just plain stupid; “I live on your soil but your laws don’t apply to me because I say so.”

    Here, youtube is claiming something specific (that Invidious violates a TOS agreement which Invidious agreed to) which is verifiably false - Invidious never agreed to the TOS for the API, and doesn’t have to, because Invidious doesn’t use the API. Invidious works by communicating with YouTube and scraping data from the responses. There’s legal precedent that this is legal (although, LinkedIn’s ongoing battle with HiQ may overturn that precedent, but it hasn’t yet). That’s one of the reasons that most services like youtube offer an affordable API in the first place - 3rd party tools using web scraping is much more expensive for them.

    YouTube could still potentially legally force them to stop by changing the TOS of the service itself, but there could be other implications of that, so we’ll see what happens. As FOSS, it’s unclear what they would even do, there are hundreds of hosts.