• 5 Posts
  • 357 Comments
Joined 3 years ago
cake
Cake day: July 2nd, 2023

help-circle







  • My big reason would be “it hurts readability”. That is, when writing code, readibility for others who aren’t familiar with it (including future me) is my top-priority, and that means indentation and alignment are HIGHLY important, and if I spend the time to write code with specific indentation and alignment, to make it readable at a glance, I want to be certain that it’s always going to display exactly that way. Tabs specifically break that guarantee, because they’re subject to editor settings, which means shit like the below example can occur:

    I write the following code with an editor that uses a tab size of 4.

    myObject.DoSomething(
        someParameter:      "A",
        someOtherParameter: "B",
        value:              "C");
    

    If someone pulls this up in an editor that uses a tab size of 8, they get…

    myObject.DoSomething(
        someParameter:          "A",
        someOtherParameter:     "B",
        value:                          "C");
    

    Not really a big deal, in this simple case, but it illustrates the point.

    My second reason would be that it makes code more difficult to WRITE, I.E. it’s not that hard to insert spaces when you mean to insert tabs, considering that you’re not LITERALLY using only tabs just only tabs for indentation and alignment. And if you do accidentally have spaces mixed in, you’re not going to be able to tell. The guy on another machine with different editor settings will, though.

    I’m aware there are fonts that can make spaces and tabs visible and distinct, but that sounds like a NIGHTMARE to write and read code with. I mentioned above, my top priority is easy readability, and introducing more visual noise to make tabs and spaces distinct can only hurt readability.



  • JakenVeina@lemm.eetoMemes@sopuli.xyzRelatable
    link
    fedilink
    English
    arrow-up
    13
    ·
    1 year ago

    It was one of those tall, thin church candles that you normally put out with a long handheld suffocator. Me, I tried to just jump for it. Came down awkwardly on one of the thing’s feet, lost my balance, and my leg crumpled in under me as I fell.



  • You’re right to think that “since it’s open source, people can see what it’s doing and would right away notice something malicious” is bullshit, cause it pretty much is. I sure as hell don’t spend weeks analyzing the source code of every third party open source package or program that I use. But just like with close-source software, there’s a much bigger story of trust and infrastructure in play.

    For one, while the average Joe Code isn’t analyzing the source of every new project that pops up, there are people whose job is literally that. Think academic institutions, and security companies like Kaspersky. You can probably argue that stuff like that is underfunded, but it definitely exists. And new projects that gain enough popularity to matter, and don’t come from existing trusted developers are gonna be subject to extra scrutiny.

    For two, in order for a malicous (new) project to be a real problem, it has to gain enough popularity to reach its targets, and the open source ecosystem is pretty freakin’ huge. There’s two main ways that happens: A) it was developed, at least partially, by an established, trusted entity in the ecosystem, and B) it has to catch the eye of enough trusted or influential entities to gain momentum. On point B, in my experience, the kind of person who takes chances on small, unknown, no-name projects is just naturally the “exceptionally curious” type. “Hmm, I need to do X, I wonder what’s out there already that could do it. Hey, here’s something. Is it worth using? I wonder how they solved X. Lemme take a look…”

    For three, the open source ecosystem relies heavily on distribution systems, stuff like GitHub, NuGet, NPM, Docker, and they take on a big chunk of responsibility for the security and trustability of the stuff they distribute. They do things like code scanning, binary validation, identity verification, and of course punitive measures taken against identified bad actors (I.E. banning).

    All that being said, none of the above is perfect, and malicious actor absolutely do still manage to implant malware in open source software that we all rely on. The hope is that with all of the above points, as well as all the ones I’ve missed, that the odds of it happening are rare, and that when it DOES happen, it’s way easier to identify and correct the problems than when we have to trust a private party to do it behind closed doors.

    Great recent example, from last year: https://www.akamai.com/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know

    Me, I see this story as rather uplifting. I think it shows that the ecosystem we have in place does a pretty good job of controlling even the worst malicious actors, cause this story involves just about the worst kind of malicous actor you could imagine. They spent a full 2 years doing REAL open source work to develop that community trust I talked about, as well as maintaining a small army of fake accounts submitting support requests, to put pressure on the project to add more maintainers, resulting in a VERY sophisticated, VERY severe backdoor being added. And they still got found out relatively quickly.