• 0 Posts
  • 11 Comments
Joined 1 year ago
cake
Cake day: June 27th, 2023

help-circle

  • I agree with both your statement about AI training and Sweeney. However, I do believe there is a legitimate argument for using generative AI in game development, and I therefore also think Sweeney has a legitimate point, even if he’s doing it as a reaction to Steam.

    Something oft acknowledged as okay in art (or any creative endeavor) is inspiration. Legally, we can really go even further, saying that copying is okay as long as the thing being copied is sufficiently transformed into something that can be considered new. Say, for example, different artists’ versions of a character such as Pikachu. We might be able to recognize them all as Pikachu, but also acknowledge that they’re all unique and obviously the creation of one particular artist.

    Why is this process a problem when it’s done with technology? I, as a human, didn’t get permission from someone else to transform their work. It’s okay when I do it, but not when it’s done algorithmically? Why?

    I think this is a legitimate question that has valid arguments either way, but it’s a question that needs to be answered, and I don’t think a blanket response of “it’s bad because it’s stealing other people’s work” is appropriate. If the model is very bad and clearly spits out exact replicas of the inputs, that’s obviously a bad thing, just as it would be equally bad if I traced someone else’s work. But what about the models that don’t do that, and spit out unique works never seen before? Not all models are equal in this sense.


  • Every single answer here is wrong in some way, and I’m very surprised nobody has given the correct answer. And to correct you, OP, Android has never had consistent update support.

    It’s true that it stems fundamentally from the hardware drivers. But it’s not necessarily a problem with Android itself.

    First, Android utilizes the Linux kernel. Linux maintains all drivers within the kernel, and they mostly tell closed-source drivers to fuck off. That being said, you can still run closed-source drivers on Linux, but it’ll be up to the driver-maker to maintain compatibility between kernel versions, not the kernel maintainers. This is CRITICAL to know in order to answer the question correctly.

    Hardware vendors like Qualcomm don’t want to open-source their drivers, and thus don’t want to upstream them to the Linux kernel. They also often only offer limited support unless you pay for it. For Qualcomm this has traditionally been 2 years. I think now it might be 3, but let’s go with 2 for the sake of this discussion.

    Thus, if I’m a phone-maker using Qualcomm chips, as are most phone-makers, then unless I pay Qualcomm extra money, they’re only going to guarantee support for 2 years. After that, updating Android further (which usually requires updating the kernel, too) could break the hardware drivers and I’d have no way to fix it. Thus, I only offer my customers support for 2 years at maximum.

    What has Google been doing to fix this?

    Well, several things. First, Google has been asking all hardware-makers to pretty please upstream everything they can into the Linux kernel. This has had decent success, but not everyone will do this. Google has also been upstreaming as much of the Android kernel as possible into the Linux kernel to minimize differences, with the ideal being that the Linux kernel and Android kernel are exactly identical.

    Additionally, Google has developed the Generic Kernel Image, or GKI, which presents a Kernel Module Interface, or KMI. This KMI is a stable interface through which hardware drivers communicate with the rest of the kernel. This is the solution to closed-source drivers. If your KMI doesn’t change and a given hardware module was written against it, you can keep updating indefinitely even when the hardware module is out of support, until you need to change the KMI again, likely for new hardware features.

    Google tried getting the KMI upstreamed into the Linux kernel, but the Linux maintainers seem fairly skeptical of it since it goes against their driver philosophy.

    In any case, Linux has LTS releases that are supported for 6 years. They release a new LTS every year. Each year, Google selects the latest LTS and builds the latest Android version against that release. They can add to the KMI when this happens, but it is frozen for that kernel version from then on. From there, they keep building Android against that kernel version until it is no longer supported.

    Let’s take Linux 5.10 for example. There is android12-5.10. Linux 5.10 is supported for 6 years, so you will also see android13-5.10, android14-5.10, etc. Additionally, Linux 5.15 is an LTS release and was released the year after. So there will be an android13-5.15 that may support newer hardware features than android13-5.10, but they will otherwise both be Android 13. There will also be android14-5.15 and so on until the 5.15 kernel goes out of support.

    I hope that example made sense! This means for a given device releasing with GKI support, it can get up to 6 years of Android updates without breaking hardware drivers. Google started mandating GKI support with Android 12. You won’t get new hardware features introduced by newer kernels or KMI versions, but that doesn’t matter on a phone that doesn’t get new hardware anyway, so you’re not really missing out on anything. This is how Google is making updates more consistent on Android.

    EDIT: You might ask, how the heck do custom ROM developers do it, then? How can they pump out new Android versions 5, 6, even 7 or more years after the device is out of support? The answer is, it’s complicated. The key here is the “shim”, which is basically just them reverse-engineering the hardware drivers (called blobs) until the hardware works. They do it on hard mode, essentially. Much respect to all custom ROM devs.

    EDIT2: And to answer how this compares to Windows: Windows has offered a stable interface for drivers to hook into for years and years, called an ABI, or Application Binary Interface. Microsoft’s approach has been “Never fuck with the driver ABI or you die, only add to it, never remove” and so it has been for decades. This is why extremely old programs still work fine on modern Windows for the most part. They only ever disable old parts of the ABI if it’s a major security vector, and even then they try to work around it so as not to break compatibility. They’ll deprecate old APIs in favor of new ones, but the deprecated APIs will still work, you’re just not supposed to use them for newly-developed programs.



  • Imagine I’m a car salesman who doesn’t give a shit about EVs. I just want to sell a car.

    “This car right here, you can fill 'er up in 1 hour! Oh but this feller, well she only takes 60 seconds, and has twice the range to boot!”

    The average person isn’t going to care that the first car is an EV and the second car is gas-powered.

    Most people can’t afford to get charging set up at home for overnight charging, either. You’re also not considering emergency scenarios where people won’t have time to wait an hour for their vehicles to charge.

    The scenario you’re imagining is an ideal scenario, not working with the current reality we have right now. The industry is working on making EVs charge extremely quickly because they believe it is a major selling point for their vehicles. Which, for the average person, it absolutely is. If EVs want to outsell gas-powered vehicles consistently, they need to meet the basics of being able to fill up quickly and having identical range.



  • In summary: (spoilers ahead)

    AI created -> AI becomes monk, this is good AI -> bad AI also created, controlled by single mastermind AI -> bad AI kill humans -> Overwatch created -> good AI sacrifices herself to free other AI from bad AI mind control, thus becoming AI Jesus -> AI now have free will. Some become good, some stay bad. -> optimistic because AI Jesus saved humanity from being killed and now Overwatch is winning the war against bad AI

    That’s about it.