moonpiedumplings

Lol I misread it too.

There is literally no way to do performant e2ee at large scale. e2ee works by encrypting every message for every recipient, on the users device.

At 1000 users, that's basically a public room.

I have been using your stuff since they were called toolpacks.

https://moonpiedumplings.github.io/playground/ape-experiments/

Welcome to Lemmy, Azathothas. It's nice to see more and more usernames I recognize show up here.

There a source port of at least portal 1.

https://github.com/AruMoon/source-engine

Here's the active fork of the original project. Going through the issues of the original project, it seems to have support for building for 64 bit platforms.

No portal 2 support though. Although mentioned in the issues of nileusr's repo is this: https://github.com/EpicSentry/P2ASW , which is interesting

Unlike a remote desktop, Puter is entirely in Javascript, where all the code runs on the user's local device, in their web browser. This makes it vastly more resource efficient than a full virtual machine (or container if you are using something like kasmweb), and thereby cheaper to set up.

It doesn't work for everything, but for the apps that do run a browser, like VSCode, it offers a much cheaper way to run those in a whole "environment" (rather than deploying them seperately). It's overall way less costly to VSCode remote into one server with 4 GB of ram, then it is to deploy a 4 GB ram instance just so there is enough ram for a GUI.

But wait! Why would a corporate product come with a variety of games for people to play? 🤔

That's because although this is a legitimate product, and a legitimate business, the true, actual usecase of Puter (and similar web desktop environments) is for students who want to play arcade games during class. Because of how efficient and easy they are to host, they can be hosted for free on a variety of platforms, allowing students at middle and high schools (12+ years old, but before college), to get around content blocking restrictions by rapidly migrating it from one hoster, ip address, or domain name to another if it gets blocked. This lets them access arcade games during class so they don't get bored.

Comparatively, the free VPS tiers often do not have enough resources for a desktop (plus gaming through remote desktop kinda sucks), and students aren't going to be eager to pay for stuff (have you seen AWS ec2 prices?!?).

Puter does not seem to have this (at least, not explicitly), but a very similar project, AnuraOS comes with a "web based proxy", that allows users to get around content filtering systems and view other sites that would normally be blocked.

I think the mistake is they titled it "The last note taking app you'll ever need" instead of "The last note taking app I'lll ever need"

Yes, seriously. The article seems to talk mostly about their personal usecases, which is fine. This app is great and it works for them. But it won't work for everybody and the title should probably respect that instead of having a grating title that evokes a knee jerk reaction.

Databases are annoying it is legitimately more difficult to export data from a database to another, than it is to copy markdown notes from one folder to another. In addition to that, there are also tools that process markdown and do cool stuff with, like pandoc, beamer, revealjs, etc, which can't really be done with the more opaque database format.

Also this notetaking service only appears to work while online. Again, fine for them — but a dealbreaker for many people.

Debian's install wizard has a few frustrations in it. Like here's an example: https://moonpiedumplings.github.io/projects/build-server-3/#installing-debian

You cannot simply click next and get a working Debian system all the time.

There is also the root/user password thing (and no, "read the content" does not work if you just said click next + other installers don't have this confusion) + a few other stuff.

Google Chrome of Linux

It's more like Chromium, the engine behind Chrome, to be precise. It eats up marketshare by essentially being anti-competitive, and making it more difficult for alternate engines to keep up with the fluctuating and undefined web standards.

Poettering hasn’t even worked at Red Hat for multiple years now.

No, he now works at Microsoft, which is famous for it's Embrace, Extend, Extinguish strategy for consuming open source and open standards.

But despite that, I'm actually not worried about systemd being taken over by a corporation and being completely used to dominate Linux. Unlike consumer software, where companies seem to be willing to take a step back and allow other corporations to monopolize a slice of the market dedicated to a usecase, corporations actually seem willing to share in the server space.

Systemd also seems to be designed with a very specific philosophy in mind, which is vastly different from Chromiums "Alright, time for a new web standard that Firefox and Safari will have trouble implementing!". Systemd, is essentially designed to replicate features of Kubernetes.

Kubernetes is (buzzwords incoming), a clustered, highly available, multi tenant, declarative, service manager and job scheduler. To break down what that means:

• Multi tenant: There can be different "users" on a Kubernetes cluster, which can be granually given access to different resources or capabilities
• Declarative: All of the Kubernetes config, roles, users, and jobs, and can be declared as code, "yaml".
• Service Manager: Kubernetes can run services, specifically containers (this is important to note).
• Job Scheduler: Users can start short or long running "jobs"
• Clustered: Kubernetes can combine resources from more than one physical or virtual server into a cluster. It does not literally combine them, but rather it shifts around services and jobs to make more room. Some services can take direct advantage of this though, where running multiple instances of them does let you combine resources.
• Highly Available: If any single "node" of a kubernetes cluster goes down, the services Kubernetes runs, and Kubernetes itself, stay active.

Systemd is essentially trying to Kubernetes, without the clustering and highly available parts of Kubernetes. It has:

• Multi tenant: This is what polkit, and logind do. They give users the ability to run long running services, but control the resources and capabilities those users who have access to
• Declarative: Systemd doesn't use yaml like kubernetes, but instead it uses the ini file format — but almost everything in Systemd can be declared as an ini file.
• Service Manager: This one is mostly self explanatory — but what's important to note is the focus that systemd has on containers. There is support for OCI containers via podman quadlets, but Systemd also has it's own container format that it can launch rootlessly, and built on top of this is systemd portablectl, which is essentially an application container format, similar to docker. You tell systemd to run a service with a root image of one of these containers, and it does so.
• Job Scheduler: Timers, but it's not a full featureset. Perhaps Systemd doesn't care about this because people can simply run commands after they are ssh'ed in.

Now, based on the assumption, I can make some predictions about what features systemd will add next. Maybe these are wrong, but eh.

• Firewall service: Kubernetes has something akin to a firewall, but mostly this prediction is because Linux doesn't really have a declarative firewall. Systemd kinda already has something similar but it's not complete.
• More advanced manipulation of user resource and capability constraints. It looks like there is some simple cgroup stuff, but I do think we are going to eventually see Seccomp and other restrictions.
• A "container repo" for portable/nspawn services. I think they used to have one for OS containers for machinectl, but I can't find it. But If they are actually trying to be Kubernetes, then I would expect to see a setup where you can have a file declaring a service, and then it pulls the container image for that service and then runs it.

Now, "one node Kubernetes" probably isn't the best choice for a normal server or desktop distro. (Actually I love Kubernetes as a server but that's a different discussion). But it's the most popular choice, so I think people should be aware of the architecture and intent. Especially if you dislike systemd, you should understand what changes it makes, why, and how they will impact the Linux world.

Kubernetes handles everything, except for booting the system, being a kernel, and starting itself up, and connecting to the network. Core services like DNS are actually containers ran within Kubernetes. The "firewall" (network policies) are also containers. If systemd truly wants to be Kubernetes, it seems to be trying to be even more, where consuming things like booting with systemd-boot and connecting to the network with systemd-network. I'm not personally concerned, because Kubernetes has consumed the server world and that hasn't seem to have gone wrong, but I can understand why people would be concerned.

@[email protected]

Or is it: @[email protected]

https://games-on-whales.github.io/

https://github.com/giongto35/cloud-morph

Alright, this is gonna be long.

Firstly, yes, different static site generators have different templating langauges. But just like normal programming languages, it is easy to transition from one templating langauge to another. If you take a look at the syntax:

• Pelian: https://pypi.org/project/Jinja2/
• Hugo: https://pkg.go.dev/text/template, https://pkg.go.dev/html/template

Not drastically different, but reading the docs, they are all similar enough, and easy to learn.

I wouldn't call go's templating language "esoteric", but it should be noted that jinja2 is has other uses, most notably it is the templating engine that Ansible uses.

As for the docs... This could probably be a blog post by itself.

Firstly, take a look at this website: https://killedbygoogle.com/ . Google has created and then killed 296 projects, many of which were actively used and working. Why?

This is because, internally at Google, you get promoted if you either A: write software, or B: add more features to software. So what happens is people write software, get promoted, and then realize they don't get paid more if they actually maintain that software, so they just kill it. Also, they forget to write documentation (because it doesn't pay more or get you promoted).

Hugo, is by a Google Engineer, and it shows (or at least, it used to). Software by Google has two distinct characteristics (actually 3 if we count being written in Go).

• It has every feature you could ever want, even stuff you haven't heard of
• And it's poorly documented. Or not at all lmao.

But, "being poorly documented" is not a permanent fixture of this software, but instead something that mostly persists for as long as it's Google software. Often, these projects get "adopted" by the wider community, who fixes up their documentation. Looking at hugo's docs, it doesn't seem be nightmarishly bad, especially for the core, main set of features. Like the setup docs appear to be clear (although a more complex process than alternatives).

But like, for search options: https://gohugo.io/tools/search/ . That google software pattern continues. There are like 10 options on the page, and no docs from hugo on their usage/installation lol.

Anyway, I would recommend eithier Pelican or Jekyll, given your requirements. Because everything you write is in markdown, it will be fairly easy to move from one static site generator to another, even if you are dissatisfied.

Also, kinda sorta relevant:

(source)

But the point I'm trying to make is the same. Don't agonize over selecting the perfect static site generator.

I already made a comment but you should also look at rocketchat and revolt, since they are basically FOSS discord clones

(I saw comments in the thread about wanting audio only calls.)

It's actually not that hard. (Well it is, media and networking are hard, but)

I think the problem is that when people search for something better than Teams (or any other software), they confuse "better than", with a mostly nonexistent "best". In doing so, they skip over the way every single thing people suggest is "good enough".

Like, following this thread, we went from "I want a teams (voice/video/chat) alternative" to "Yeah I don't like Jami because it leaks metadata." How did we go from wanting a teams alternative, to wanting privacy with no metadata leakage? Those are very different things, and you make tradeoffs if you take one set of feature over the other. If you just add "no metadata leakage" on top of your current wishes, then you are probably going to be disatisfied with every option given.

Or "Firewalls and hole punching!" (implying a p2p architecture) and "depends on peers being reliable" (being frustrated with the pitfalls of a p2p architecture). Again, wtf? Of course there is software that is both p2p and client server, but that is hard and tradeoffs will end up being made, even purely in what the developer spends their limited time on.

This person just needs to get out of their head, whip up deployments for every software (or suite if there is more than one) mentioned in the thread, and pick the one that looks the nicest.