• 0 Posts
  • 17 Comments
Joined 1 year ago
cake
Cake day: August 8th, 2023

help-circle













  • I’m interested in examples. The West loved Gorbachev, is that why he was deposed? Were all the satellite countries that all split off during the collapse of the USSR being manipulated by the West to do so? I agree that Putin is essentially a backlash reaction by the Russian powers that be, and they’ve been pretty open about getting the band back together, but why. I see them looking back to the glory days and wanting them back, but for a while there Russia was looking pretty good on the global stage. They had oil money, business, influence but it wasn’t enough. That’s the part I don’t get: what is enough for Russia, and is it cultural, historical, foreign influence, or something else that drives them. They seem to love shooting themselves in the foot and I don’t understand why.


  • nxdefiant@startrek.websitetoLinux@lemmy.mlXZ backdoor in a nutshell
    link
    fedilink
    arrow-up
    4
    arrow-down
    1
    ·
    edit-2
    8 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.


  • I see a dark room of shady, hoody-wearing, code-projected-on-their-faces, typing-on-two-keyboards-at-once 90’s movie style hackers. The tables are littered with empty energy drink cans and empty pill bottles.

    A man walks in. Smoking a thin cigarette, covered in tattoos and dressed in the flashiest interpretation of “Yakuza Gangster” imaginable, he grunts with disgust and mutters something in Japanese as he throws the cigarette to the floor, grinding it into the carpet with his thousand dollar shoes.

    Flipping on the lights with an angry flourish, he yells at the room to gather for standup.


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

    It’s not uncommon to keep example bad data around for regression to run against, and I imagine that’s not the only example in a compression library, but I’d definitely consider that a level of testing above unittests, and would not include it in the main repo. Tests that verify behavior at run time, either when interacting with the user, integrating with other software or services, or after being packaged, belong elsewhere. In summary, this is lazy.