• nickwitha_k (he/him)@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    Seems rather bizarre to me, though it could make sense for some non-technical roles. For developers, seems a bit impractical; much of language documentation is online and odd errors, common and esoteric, are frequently completely absent from docs. This seems likely to require devs to either use unauthorized devices or waste time digging through source (possibly for the programming language itself) to figure things out.

    However, the remark about root access makes me hope that there are not people logging into systems at Google as root. A sudoer, sure, but root is a big no-no.

    • RealAccountNameHere@beehaw.orgOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      1 year ago

      su root

      rm -rf /SteveHuffmanData/SearchHistory/RealStuff

      mv HorseNPigPorn.jpg LemonParty.html TubGirl.png SteveHuffmanData/SearchHistory

    • skwerls@waveform.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Seems like they could have a machine with higher level access air gapped, and a less secure machine for browsing the internet but not internal tools. Would still suck for copy paste and things of the line, but would probably work in most cases.

      • nickwitha_k (he/him)@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        I would think that this would be an approach that absolutely makes sense for corporate infra systems like domain servers, systems with access to network configs, etc.

        Maybe adding an additional security tier? Something like “sandbox dev” where new third-party libraries and technologies can be tested and a “production dev” which is more restricted. That might be the “right” way.

        The problem that I’d see is that productivity, development velocity, and release cadence would all take a nose-dive as software engineers have to continually repeat work, roughly doubling the real amount of work needed to release any piece of software. This would likely be seen as incompatible with modern business and customer expectations.