• 5 Posts
  • 44 Comments
Joined 2 years ago
cake
Cake day: July 26th, 2023

help-circle
  • Yes, but this comes with restrictions on distribution of your binary/code/artifacts.

    I see the value in these restrictions, but i also see why these libraries are avoided in commercial settings. These terms often come as a suprise from my understanding.

    The EUPL solves this by only making claims of the actual modifications to the EUPL licensed components, not any third party user code.

    This license (EUPL) was designed with cooperarion as the primary motive, and this is very valuable in my opinion.

    I believe the reason we see so much permissive code is because of said suprises with the GPL’s, it defeats the utility of the license itself. I say this as an avid GPL lover, but i have also seen projects like libopencm3, which desperately needs EUPL.

    On the other hand we have projects like Linux and VESC, where we absolutely positively need to kill user-exploatation dead in its tracks, mostly since it is an end-user product. The GPL serves its purpose perfectly here.

    Also, you might note that the MPL is a valid choice here, but it does not offer the same protection in the case of third party extension of the licensed code, since it is file-based, in essence.

    Ive actually spent a good amount of time looking into licenses, would love to hear more of your thoughts.

    Here is a discussion and Here is the original author (i think) of the EUPL.




  • Its about the type of operations the compiler allow you to do, more or less. Like sharing mutable references, that can be independently changed in a ‘hard to keep track of’- manner. Other factors the compiler tries eliminate include buffer overruns and int overflows e.t.c.

    Rust for example sometimes makes trivial things a royal pain, see linked lists for example. It also has a gaping microdependency/supply chain attack prone ecosystem, and the compiler interface is also not stable (afaik, caused some issues in linux). There is also no spec.

    I have experience of both, and i love both, but C is my fav. Its often trivial to imagine the codegen with C, and there are no shortage of quality compilers. The language is also small enough that implementing a compiler is actually feasible.



















  • Can never seem to understand this reasoning. Musk seems to largely have solved the censorship problem on twitter, which could be regarded as a vital piece of modern dempcracy (along with the rest of the internet, which mostly suffer from said censorship).

    While at it he weeded out some traitors, who actively sabotaged during this period. Im well aware that corporate takeovers arent something “good”, but this one actually seems to make free speech a first class value.

    This censorship is imposed by advertisers, which is somehow celebrated. Were talking disney, coca cola, whatever… These all want to control what you can or can not hear, and people are celebrating it?

    The proper response to advertisers trying to co trol democracy is absolutely “go fuck yourself”, this should be the norm.


  • 3h5Hne7t1K@lemmy.worldtoSelfhosted@lemmy.worldXMPP Server?
    link
    fedilink
    English
    arrow-up
    5
    arrow-down
    1
    ·
    1 year ago

    We dont want a bunch of proprietary extensions to an open communications standard, do we? This is something positive.

    That said, I dont have much hope for matrix. Implemented in python with the initial goal of “bridging every chat platform in existence” is just bound to be a disaster.

    Maintaining anything beyond a couple of hundred lines in python becomes tedious imo.

    The rewrite in go has been spoken about since like 2018, and matrix.org still runs synapse iirc. Synapse should have been trashed immediately after MVP demonstration.

    Theres also conduit, but to be honest, i feel like the lesson here is to avoid feature creep. Safe, fast and distributed dm text chat should have been the target functionality, with a lean, mean codebase.

    Thanks for coming to my ted talk