Preston Maness ☭

  • 0 Posts
  • 20 Comments
Joined 2 years ago
cake
Cake day: March 2nd, 2022

help-circle









  • Absolutely not, and this article goes into quite a few reasons why:

    https://blog.brixit.nl/developers-are-lazy-thus-flatpak/

    Sadly there’s reality. The reality is to get away from the evil distributions the Flatpak creators have made… another distribution. It is not a particularly good distribution, it doesn’t have a decent package manager. It doesn’t have a system that makes it easy to do packaging. The developer interface is painfully shoehorned into Github workflows and it adds all the downsides of containerisation.

    While the developers like to pretend real hard that Flatpak is not a distribution, it’s still suspiciously close to one. It lacks a kernel and a few services and it lacks the standard Linux base directory specification but it’s still a distribution you need to target. Instead of providing seperate packages with a package manager it provides a runtime that comes with a bunch of dependencies.

    If you need a dependency that’s not in the runtime there’s no package manager to pull in that dependency. The solution is to also package the dependencies you need yourself and let the flatpak tooling build this into the flatpak of your application. So now instead of being the developer for your application you’re also the maintainer of all the dependencies in this semi-distribution you’re shipping under the disguise of an application. And one thing is for sure, I don’t trust application developers to maintain dependencies.

    Even if there weren’t so many holes in the sandbox. This does not stop applications from doing more evil things that are not directly related to filesystem and daemon access. You want analytics on your users? Just requirest the internet permission and send off all the tracking data you want.

    Developers are not supposed to be the ones packaging software so it’s not hard at all. It’s not your task to get your software in all the distributions, if your software is useful to people it tends to get pulled in.

    Another issue is with end users of some of my Flatpaks. Flatpak does not deal well with software that communicates with actual hardware. A bunch of my software uses libusb to communicate with sepecific devices as a replacement for some Windows applications and Android apps I would otherwise need. The issue end users will run in to is that they first need to install the udev rules in their distribution to make sure Flatpak can access those USB devices. For the distribution packaged version of my software it Just Works™




  • I don’t think Red Hat is violating GPL. For sure it’s not violating the legal terms of it (I’m fairly certain the army of lawyers RH and IBM have at their beck and call made sure of that) and I don’t think it’s violating it’s spirit (at least not yet) – they are still contributing any changes and their customers still get access to the source code.

    They are absolutely violating the spirit of the GPL. Telling your customers that you will not keep them as customers if they exercise their rights under the GPL is as clear a spiritual violation as it gets. And whether they are violating the letter of the law is an unresolved question.

    The way I see it, RH wants to be the only game in town providing service contracts for their own product which is fair game, imho. The problem with Rocky is that they also stand to make money out of the same source code which is the disingenuous part, in my opinion.

    The problem is that the software is not “their product.” Free Software is a collective endeavor that RedHat contributes to. It is not a product that belongs to them. The product is the support, and RedHat, by virtue of the GPL and the nature of Free Software, cannot stake an exclusive claim to the support.





  • systemd is a godsend when you need service control while getting actual work done, at scale.

    there are legitimate things to criticize but in general the rants are incompetent preaching to the uninformed.

    Service control was systemd’s main benefit and what it most excelled at. Having shell scripts for everything was a legitimate pain. It was all the other pieces of the ecosystem that it was wanting to subsume that got people upset (logging, cron, time, hostname, login, etc). Journald/binary logs was the main sticking point that I recall, though I figured it was a trade-off that was worth it, especially since you could have journald keep dumping to text anyway.