• 0 Posts
  • 27 Comments
Joined 2 years ago
cake
Cake day: July 4th, 2023

help-circle

  • douglasg14b@beehaw.orgtoAnnouncements@lemmy.mlBreaking Changes in Lemmy 1.0
    link
    fedilink
    English
    arrow-up
    2
    arrow-down
    2
    ·
    3 months ago

    Why?

    I know the knee jerk reasons of course.

    However, GitHub is a fantastic ecosystem for an application to thrive. Contributions on other platforms are greatly reduced.

    Then again, the actual Lemmy development is a bit of a mess.

    Once it gains critical mass of engaged developers, that’s a good time to migrate off GitHub. Doing it earlier just slows the project down.


  • And your alternate options are what?

    Why should we ditch Firefox now? Because they have moved slightly in the direction we dislike but are still light years ahead on privacy?

    This is the tech version of single issue voting. All the nuance is lost and ignored, and it’s just a knee jerk after knee jerk.

    Mozilla is doing this because funding is difficult, if you wanted a free and open web then you should have been donating to the foundation. To some degree we all should have. The majority of their funding comes from Google, when that gets cut they have to make huge changes to their organization or they will completely die.

    That’s the reality we live in all those Mozilla engineers have to be paid money, they aren’t working for free. How do you expect a company to function without an income source?

    Have you thought about this at all before making statements like those you have made?


  • Like I said, I’m not arguing that many apps are built as electron apps when they’re just glorified web apps. Though I’m neutral on whether that’s a bad thing or not. I’m definitely against apps being built with electron that don’t really have UIs, defeating the entire point of electron and friends…

    VSCode is another example you’re missing. And they have put a LOT of work into making as many features available in the web-version as possible, the feature parity isn’t an accident.

    Or Obsidian.

    Examples aside, you might be surprised by applications you may not think of as not using native features, that rely heavily on them, expecting to be executing in a Node environment and not a browser one. Especially on the networking and process side. Browsers are extremely restrictive.


  • What are you talking about…? Please re-read my comment above :/

    An electron app is a natjve application that renders a browser based UI. You appear to be conflating the browser-based UI with the whole “native application” thing.

    It comes with all the advantages a native application does, like having hardware access, working natively offline, working with the filesystem, interfacing with the OS and installed OS packages, being able to use other native binaries, being able to use more native networking capabilities…etc

    Sure lots of electron applications that people make could just be a web app, I’m not arguing that.

    I am, however, pointing out that you are grossly incorrect that electron (and all other technologies like it, we’re not really just talking about electron here) is 'just a web app". It’s a native application server and a web-based UI, which means I can write an application in C# with all of the .Net advantages, with a web UI, that runs natively on your device for example.

    This lets me ship a product much faster than if I was going to build that UI in QT or GTK, with a significantly upgraded user experience that is consistent across all platforms.




  • Which is… Also a real desktop app. This shallow take is getting incredibly old, and doesn’t even contribute to actual valuable discussion… If you don’t see the value in this being shipped, then why try and tear the value down for others?

    I main C#, and even I would rather build cross platform full applications with electron than any of the other options available. I’m definitely choosing it over QT or gtk. Why? Because I can actually ship the project with all the necessary features, in good time, and bake in a great user experience.

    That’s the difference here. Practical problems vs reality. Shipping the project & features vs not.

    Yes, there are many successful applications not built with electron, ofc there are, that’s not my point. My point is that the productivity difference is such that it’s the difference between not building the thing vs building it and successful shipping it to users. You can argue and shit on the difference, but at the end of the day the above is what really matters.








  • Lemmy is… Not distributed computing.

    If each instance is a separate application than must scale on it’s own, then no distributed computing is occuring.

    There is one database, and you can have the instance itself behind a load balancer.

    Lemmy is not a distributed program, you can’t scale it linearly by adding more nodes. It’s severely limited by it’s database access patterns, to a single DB, and is not capable of being distributed in it’s current state. You can put more web servers behind a load balancer, but that’s not really “distributed computing” that’s just “distributing a workload”, which has a lot of limitations that defeat it being truly distributed.

    Actual distributed applications are incredibly difficult to create at scale, with many faux-distribited applications being made (Lemmy being n-tier im a per instance basis).

    Think of Kafka. Kafka is an actual distributed application.


  • Cloud computing is… Not distributed computing.

    We’re talking about pushing compute workloads across a distributed set of devices where that workload is linearly scalable by the number of devices involved, compute, storage, failovers…etc scale elegantly. Cloud computing can give you the tools to make such a thing a reality within the scope of the cloud provider, but it most definitely is not distributed computing just by existing.

    Also the fediverse is NOT distributed computing either, at least for Lemmy. There is no distributed compute available for Lemmy. You can’t have a few hundred users toss up their own compute to handle loads for an instance. Each instance is limited to a single database, and can have webservers behind a load balancer to spread out the compute. And that’s about the best you’ve got. Not distributed, you can’t just spin up 100 nodes for a Lemmy instance to handle more load and everything “just works”. It’s a very “classic” architecture in a way.

    A K8 cluster isn’t distributed computing until you build a distributed application that can elegantly scale with more and more nodes. And is fault tolerant to nodes straight up dying.

    Kafka for example, is an actual distributed application. One which you could run on a K8 cluster, it self-manages storage, duplication, load balancing, failovers, rebalancing…etc elegantly as you add more nodes. It doesn’t rely on a central DB, it IS the DB, every node. Lemmy is not.