• 9 Posts
  • 51 Comments
Joined 3 years ago
cake
Cake day: August 10th, 2023

help-circle

  • Openbsd is definitely more secure than secureblue. There is only so much you can do to handle the massive monolithic architecture of the Linux kernel. Further down the stack, many parts of Linux, like sudo, dbus, or systemd are regularly hit by zero days. The SELinux domain architecture that Secureblue is interesting, but SELinux is extremely complex and difficult to get right, compared to the much more simpler pledge and unveil sandboxing that openbsd offers.

    In addition to that, there are further issues like the problematic way that user namespaces interact with browsers. (And user namespaces are frustrating in general, secureblue actually has a short article on their problems). For maximum security, you want to sandbox tabs from eachother using user namespaces (only works on chromium btw, firefox can’t do this so it doesn’t matter) — BUT, if you run your browser in a sanbox created by user namespaces, then you can’t nest them, disallowing you from using that powerful tool to isolate tabs. So you are forced to make a choice: You can either sandbox the browser itself, in exchange for weakening the isolation between tabs, or you can strengthen the isolation between tabs, in exchange for weaking the sandbox around the browser itself. Giving the browser access to user namespaces is questionable though, because see above, user namespaces have led to a lot of vulnerabilities.

    OpenBSD’s pledge + unveil (but only on chromium again), does not really make such tradeoffs. It can sandbox tabs from eachother, while also sandboxing the browser itself. In addition to that, pledge + unveil do not present a massive kernel attack surface that people have had to restrict for having too many 0days. And this is just one of the many, many examples, where OpenBSD presents a better security posture than Linux.

    Qubes is technically Xen, a different kernel than Linux. The Xen kernel virtualizes Linux distros, from which you can manage Qubes/Xen, or do normal Linux app stuff. But nothing stops you from using a BSD virtualized by Xen for management or usage. Qubes talks about why they use Xen here — but the short version is that they did not consider the Linux kernel’s kvm secure enough for their usecase.


  • FreeBSD, OpenBSD and NetBSD are behind Linux.

    Look, I dislike permissive licenses too, but you need a source to back this claim up.

    Right now, each BSD does something special, that Linux (distro’s) can’t trivially replace, even if the usecase is more niche. NetBSD Dev’s make efforts to get it running on many devices as they can. OpenBSD (and it’s subprojects) are highly secure, moreso than Linux. Who do you think makes our beloved OpenSSH? OpenSSH noted for having very few vulnerabilities over it’s two decade long existence, and OpenBSD itself is similar, which is insane because there are products with multiple bad vulnerabilities every year (Linux being one of them…). This is due to a highly security minded architecture - one that Linux lacks.

    FreeBSD is like Linux before systemd. I like systemd, but systemd is really trying to be kubernetes on a single node. I like systemd because I like kubernetes, but I understand why someone wouldn’t like it, and I question if “single node k8s” is the best architecture for a single server or personal desktop. The ports system results in freebsd packaging many server services that aren’t packaged on Linux. Being able to manage those through the system package manager, and the conviniences that provides, is nice.

    Different, and not popular don’t mean bad.








  • This may sound kind of weird, but do you really need a communication platform for a LUG?

    Our local LUG uses meetup and a website for advertising and telling people when we meet (once every two weeks at the same spot). (Okay I guess the one time our spot was closed and we had to track down people’s phone numbers to inform them of the new spot wasn’t that fun).

    Anyway, we have a mailing list, an irc, and a matrix chat bridged to the irc, but they are effectively dead and no one uses them. The lack of activity on them makes me wonder if you really need to have a chatroom to run a LUG. We seem to get by just fine, for the most part.








  • Yes and no. There are many things that are much easier with Kubernetes, once you figure Kubernetes out.

    High availability is the most notable example — yes, it’s doable in docker, via something like swarm, but it’s more difficult. In comparison, the ideas of clustering and working with more than one server are central to the architecture of Kubernetes.

    Another thing is that long term deployments with Kubernetes can be more maintainable, since everything is just yaml files and version is just a number. If you store your config in code, then it’s easier to replicate it to another server, either internally, or if you share it for other people to use (Helm is somewhat like this).


  • This helm chart is not just matrix/synapse, but also element (web ui), and “matrix authentication service”, which adds SSO/OIDC support to a normal synapse instance, which is pretty neat. I haven’t seen any helm charts that include the full matrix stack, just separate synapse or element helm charts. And helm definitely makes deploying services to Kubernetes easier than other ways of deploying applications.

    The other reason why I like an official helm chart, is because I have seen unofficial one’s be stopped being maintained by the community member(s) maintaining them. With an official one, it will (probably) be maintained indefinitely.



  • I despise the way Canonical pretends discourse forum posts by their team members* are documentation.

    I’ve noticed they have been a bit better lately, and have migrated much of the posts to their documentation, but it seems they are doing it again.

    As this is developed, we will update this post to link to the new documentation and feature release notes.

    Pro tip: You could have just made the documentation directly, with the content of this post. Or maybe a blog post. But please stop with the forum posts. They are very confusing for people not used to these… unique locations.

    *Not that people are easily able to find this out when they don’t give any indication that the forum post is something other than just another post by a rando. Actually, I’m just guessing here, based on the quoted reply, for all I know this could be a post by someone unrelated to Canonical. The account is 3 months, and the post itself is identical to a regular forum post from a regular forum member…


  • Here’s my commentary on the options you listed in the image:

    Anaconda: They changed the licensing so that it’s not really fully FOSS, as the repos have restrictions on them. There are also other issues like this dark pattern of a download page.

    But, forgetting about the licensing or problematic company practices: The software itself is trash. Worst thing I’ve ever used. It’s sooooo slow to install packages when it’s doing the “solver” thing. You can use something faster like mamba or miniconda, but then you still have to deal with package availability being poor, as the anaconda repos don’t have everything, and much of what they have is often too old.

    Docker desktop: It’s proprietary. I mean you can use it, but you seem to be interested in open source stuff. Also see caveats to podman desktop below.

    Podman Desktop: Technically this will work. But podman desktop is really designed more for development of containerized applications, rather than developing in containers.

    Nix: Nix doesn’t work on Windows, so you would have to require WSL or something like that.

    Fedora VM: I recommend enlightenment as a desktop environment. Very small, but also modern and clean looking. You’ll have to configure it to be a bit more similar to windows, but it’s a lot more intuitive to use than i3.

    There are some other caveats to your environment. “The right .Net Sdks version” — however, the best extensions for C# development are proprietary and cannot be freely used in the fully FOSS versions of vscode.

    it also requires users to learn i3wm and possibly use the command line, which may not be ideal for everyone.

    Yeah, don’t do this. I agree with @utopiah@lemmy.ml, work with them, rather than forcing them to work with you. Collaboration goes both ways.

    Another recommendation I have is to just see how people in a similar circumstance do what you do. There are plenty of people who do software and game development on twitch, and you can just go on their streams and ask how they collaborate. One method I saw is using trello, a task management software, and artists would upload models there as deliverables. They already have their own workflow, which they probably work efficiently with. And it’s not really the job of an artist to integrate models and art into the game, that’s the programmers job.