• 1 Post
  • 18 Comments
Joined 1 year ago
cake
Cake day: June 10th, 2023

help-circle




  • Yeah, that seems bonkers, but it’s how npm works. I don’t always code in JS, but if I do: a) its code that’s going to run in a browser and b) I never ever use any JS dependencies aside from browser builtins. It’s about the only way to opt out of the dependency nightmare that is “modern web dev”.

    Ok, I lied a little bit. In my job, I sometimes do JS work on projects with Grunt, Bower, Backbone, jQuery and a gorillion other dependencies. But when I have full autonomy over a codebase like with my side projects, my style is as above.

    To qualify that even more, even in my side projects, I often use minifiers, but not ones written in JS or pulled in via NPM.

    Of course, that probably doesn’t help much when you have need of functionality that would be much less trivial to make yourself. Again at my job, we use JsBarcode to generate images of barcodes. That would be a royal pain to implement from scratch. If I needed that functionality in a side project, I’d probably just bite the bullet and pull it in from Bower with 30 other bulky dependencies. (Or more likely just refrain from taking on that particular side project. Or possibly generate barcodes server-side.)




  • Ah. Well, I still see the web interface pulling in new posts as I sit on the home page. But then, I also mentioned that my Lemmy instance (or, the instance I’ve joined, that is) is a couple of versions behind. (I’m not sure if they’re behind on both Lemmy and the UI or on just one.) If they’ve changed that behavior in newer versions, that could be why I’m still seeing the web interface pull in new posts while you don’t.

    And if that behavior is removed in the newer versions, then I can probably expect all the issues I’ve mentioned in this thread to be resolved as soon as latte.isnot.coffee updates to more recent versions of either Lemmy or Lemmy-UI or both.








  • “Given enough eyeballs, all bugs are shallow.” - Linus Torvalds

    Open Source software is (caveat, qualifier) safer than proprietary software. (And I’ll get to the caveats and qualifiers later.)

    Software exploits are possible only because of mistakes, oversights, negligence, or mistaken assumptions on the part of the developer of user of the code. More eyes on the code help suss out those mistakes, oversights, negligence, and mistaken assumptions, creating a more secure (and bug-free) piece of software.

    Besides that, companies that make proprietary software have incentives to put evil things into said proprietary software that endanger you to enrich them. (For instance, phone apps collecting personal data about you only to sell to advertising companies.) Companies that contribute to open source software also have incentives to put evil things into open source software, but when everyone has access to view the source code, it’s a lot harder to get away with that. (Not to say it’s never happened that purposeful vulnerabilities have gotten into open source software, but it’s a lot easier to catch such vulnerabilities in open source software than proprietary software.)

    As others have said, the way algorithms related to security are designed, the security doesn’t depend on keeping the algorithm secret. (But rather, keeping a “key” – a bit of data generated by the algorithm – secret.)

    Now, caveats.

    I do believe there is some extent to which open source software is trusted to be safe even when the “chain of custody” is questionable. There are ways to ensure integrity, but there are repositories such as NPM that carry large amounts of open source software that is used by huge numbers of people on a regular basis that don’t utilize sufficient integrity checking techniques. As a result, there have been a few cases where malicious code has sneaked into NPM and then into codebases.

    There are also cases where governments have gotten malicious code into open source projects. (Though, I’d expect that’s more of a problem with proprietary software, not less.)



  • Yeah. I’m definitely for some pretty seamless integration. Probably in the optimal case:

    • The wikis would be hosted on the same domain as the Lemmy servers.
    • Any account you had on the associated Lemmy server would automatically exist to the wiki as well.
    • If you were logged into Lemmy, you’d also be logged into the wiki.
    • Only mods would be able to enable wikis but the process of doing so would be trivially easy.
    • I’d personally say that it makes the most sense to just have the mods link the associated wiki from the sidebar rather than creating new special interface features to add a link outside the sidebar or whatever. (Unless some kind of plugin infrastructure that would allow that already exists.)

    But all that can be done without putting any wiki-specific code into the Lemmy or Lemmy-UI source repositories, which I think is preferable for the same reason you wouldn’t add flight simulator code to a spreadsheet application. (Ok, maybe a bad example, but you get my point.)

    Edit: And I’ll admit there are both upsides and downsides to my approach here. One downside would be that some Lemmy instances would offer attached wikis and others wouldn’t. It’s possible it also just wouldn’t catch on at all and nobody would enable attached wikis as a feature if it was a whole separate step to setting up “Lemmy”.



  • I don’t want to be constantly comparing Lemmy to Reddit, but on Reddit, the wikis were invaluable. As helpful as the threads were, the wikis frequently had amazingly useful info.

    That said, I’m not sure I think adding wikis to Lemmy is the right way to go. “One thing well” and all that.

    Maybe instead, some ancilliary wiki platform that can be run alongside Lemmy that lets a community mod easily set up a wiki that can be linked to in the sidebar?

    Or we could go really simple and just link specific posts in the sidebar with useful information of the kind you’d otherwise put into a wiki.