It is my response:

First of all, HyperbolaBSD is focused to be a minimalist operating system, so automatization is not welcomed here. Second, freedom of choice should be respected because is a way to give the option for users and distributions make the better choice under their own point of views, so force D-Bus is not the way because it's like treating us like cattle.

Independent of those points cited above, there are another issues related to D-Bus:

• Bloated and over-engineered: Its C API is very annoying to use and requires writing large amounts of boilerplate code. In fact, the pure C API is so annoying that its own API documentation states: “If you use this low-level API directly, you're signing up for some pain.”

• Absurd bugs and and conceptional problems: The bugs range from uncontrolled memory usage, over silent dropping of messages, to dead-locks by design, unsolved for up to 7 years. Looking closer, most of them simply cannot be solved without breaking guarantees long given by dbus-daemon(1), the reference implementation.

• D-Bus leaks machine-id across applications which causes privacy and fingerprinting concerns.

Further details:

• https://openwrt.org/docs/techref/ubus#w … us_vs_dbus

• https://dvdhrm.github.io/rethinking-the … ssage-bus/

• https://unix.stackexchange.com/question … -id-a-uuid

Emulatorman wrote:

zapper wrote:

I found something that I think might work as well as gimp:

https://github.com/bgrabitmap/lazpaint/

for my needs it works at least, I searched for gimp alternatives and found this,  tell me if it has what you guys need and whatever it doesn't have, feel free to mention.

Actually this one might also work:  https://github.com/glimpse-editor/Glimpse

But lazpaint requires way less depends thats why I mentioned that one first.

Glimpse forces D-Bus like GIMP, maybe you could create a feature request to make D-Bus optional for building, so we could use it as GIMP replacement.

Oh, didn't realize that... although, maybe they'd be more willing to get rid of said dependency than gimp. hmm...

What about krita?

Getting back onto that as I had that in mind, the next reaction:

I'm sorry but this report is not about the pro or cons of dbus.
As for "freedom of choice", it does not mean "having others work to implement your choice". This is Free Software here, not slavery. We already told you we welcome contributions to make GIMP work on your platform. Contributing is how you can enforce your freedom of choice, not telling us we should respect your freedom of choice (we do, as I already told in the previous message we'd happily welcome any well-done patch to make GIMP work on your OS).
So please let's stop the weird remarks on freedom of choice as we are not restricting anyone on this topic (yet it does not mean we are slaves to your desires). I hope you do understand how your previous messages didn't sound very pleasant and came out of nowhere (especially just after a message where I told you we'd welcome your contribution to make what you want happen). In GIMP, we take care of having a sane contributing environment, which I hope you understand. If so, let's stick to the topic at hand. 🙏

I don't know, that was my question. This is your OS, you tell me!

So my reaction here was:

Sorry, was not meant to attack you especially it is more a generic criticism towards D-Bus.
So I'll take the criticism thankfully and would ask: Do you have a first tip to look after for a patch? (as HyperbolaBSD won't have D-Bus integrated) Otherwise I'll look further myself for the time and come back later on. Thanks!

I've tried to be as diplomatic and friendly as possible just not to get the ticket closed. They are generic open but only with a patch. So my question is in the direction of a first starting point in general and making again clear: Hyperbola won't have D-Bus!
It's a pity that the freedom of choice is not really interesting for some projects.

Ah thanks and we have some clues (quote incoming):

You may look in our code what we use DBus for. That will only be a handful of files. For instance:

$ grep -rIl _dbus_ * --include=*.c
app/gui/gimpdbusservice.c
app/gui/gui-unique.c
app/unique.c
libgimpbase/gimputils.c
libgimpwidgets/gimppickbutton-kwin.c
libgimpwidgets/gimppickbutton-freedesktop.c
plug-ins/screenshot/screenshot-kwin.c
plug-ins/screenshot/screenshot-gnome-shell.c
plug-ins/screenshot/screenshot-freedesktop.c

The screenshot and color picker code are the use of D-Bus for portals (Wayland and sandboxed packages such as Flatpak/Snap). You might not have to care about having alternative implementations for these. The original non-D-Bus implementations might already just work fine.
The first few files are the ones you should look at:

- In libgimpbase/gimputils.c, there is only gimp_file_show_in_file_manager() implementation where you'd have to provide an alternative. As you can see, we have currently 3 #ifdef variants (one for Windows, one for macOS, and one with D-Bus).

- Then you should look at the *unique* files which is were you want to provide alternative code to handle the feature without DBus.

Also you need to update the autotools and meson files. Basically if something special must be done on this OS, then it has to be properly detected in a non-ambiguous way. In particular, even among the BSDs, it must only detect HyperbolaBSD as the other BSD are fine using D-Bus. We don't want to break perfectly working implementations.

Btw, coadde upgraded the spreadsheet with those references.

throgh wrote:

Okay, my question was within the motivation so far having a look also onto "community" and "multilib", especially "community". Because there is my beloved "Handbrake" for now. Otherwise we could see what's coming next, perhaps also some community-ports? Well, would be interesting.

For security reasons, [community] and [multilib] repos were removed in v0.4, however we will import the most important ones to [extra] repo. For that reason, we opened a thread that includes a spreadsheet with a compatibility list for v0.4 based on the applications suggested by community.

By the way, ImageMagick has trademark issues, so GraphicsMagick was made to solve that

In short, it says:

• On November 27, 2003 ImageMagick Studio LLC applied to register "ImageMagick" as its trademark, and it was awarded this registered trademark (serial number 78333969) on August 30, 2005. Those who re-distribute modified versions of "ImageMagick" (e.g. patched or improved) under license as "ImageMagick" now face the risk of arbitrary trademark infringement claims by ImageMagick Studio LLC.

It's stating that..

• GraphicsMagick never picks up new code from ImageMagick.

So it could require adaption to scripts or programs that depend on ImageMagick. Currently, g4jc is looking for patches for GraphicsMagick from Gentoo and other distros, maybe you could help him in this process too.

Hey I'd thought the Linux-kernel won't get further updates? But now the kernel was upgraded towards version 5.4.80.
How to help with the timeline for HyperbolaBSD or is this independent to be viewed at all?

Recently, we have made the decision to upgrade the Linux-libre kernel to the latest LTS version to avoid troubles with the new nftables and another core dependencies. It's independent of our HyperbolaBSD development, remember that HyperbolaBSD isn't limited to the kernel and we have plans to maintain a modified version of vanilla OpenBSD userspace adapted to our custom kernel and libc. Our main focus still on the HyperbolaBSD development, however it will take time to complete, so we made a modification in the development releases, you can see here for further details.