• 0 Posts
  • 32 Comments
Joined 11 months ago
cake
Cake day: August 8th, 2023

help-circle









  • The NHSTA hasn’t issued rules for these things either.

    the U.S. gov has issued general guidelines for the technology/industry here:

    https://www.transportation.gov/av/4

    They have an article on it discussing levels of automation here:

    https://www.nhtsa.gov/vehicle-safety/automated-vehicles-safety

    By all definitions layed out in that article:

    BlueCruise, Super Cruise, Mercedes’ thing is a lvl3 system ( you must be alert to reengage when the conditions for their operation no longer apply )

    Tesla’s FSD is a lvl 3 system (the system will warn you when you must reengage for any reason)

    Waymo and Cruise are a lvl 4 system (geolocked)

    Lvl 5 systems don’t exist.

    What we don’t have is any kind of federal laws:

    https://www.ncsl.org/transportation/autonomous-vehicles

    Separated into two sections – voluntary guidance and technical assistance to states – the new guidance focuses on SAE international levels of automation 3-5, clarifies that entities do not need to wait to test or deploy their ADS, revises design elements from the safety self-assessment, aligns federal guidance with the latest developments and terminology, and clarifies the role of federal and state governments.

    The guidance reinforces the voluntary nature of the guidelines and does not come with a compliance requirement or enforcement mechanism.

    (emphasis mine)

    The U.S. has operated on a “states are laboratories for laws” principal since its founding. The current situation is in line with that principle.

    These are not my opinions, these are all facts.











  • nxdefiant@startrek.websitetoLinux@lemmy.mlXZ backdoor in a nutshell
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    3 months ago

    A repo dedicated to non-unit-test tests would be the best way to go. No need to pollute your main code repo with orders of magnitude more code and junk than the actual application.

    That said, from what I understand of the exploit, it could have been avoided by having packaging and testing run in different environments (I could be wrong here, I’ve only given the explanation a cursory look). The tests modified the code that got released. Tests rightly shouldn’t be constrained by other demands (like specific versions of libraries that may be shared between the test and build steps, for example), and the deploy/build step shouldn’t have to work around whatever side effects the tests might create. Containers are easy to spin up.

    Keeping them separate helps. Sure, you could do folders on the same repo, but test repos are usually huge compared to code repos (in my experience) and it’s nicer to work with a repo that keeps its focus tight.

    It’s comically dumb to assume all tests are equal and should absolutely live in the same repo as the code they test, when writing tests that function multiple codebases is trivial, necessary, and ubiquitous.