4 ms·
That's the fundamental problem with DBus-exposed interfaces: they're APIs that get marketed as abstractions. APIs don't leave much room for different interpre
by jude- 12y ago
That's the fundamental problem with DBus-exposed interfaces: they're APIs that get marketed as abstractions. APIs don't leave much room for different interpretations, meaning you'll end up rewriting the component you're trying to avoid using in the first place.
- simoncion 12y agoI'm not sure what you're saying here. If you want to avoid using a particular piece of software, but need to adhere to its API, you're going to either reimplement parts of it, or use someone else's reimplementation. There's really no way around that. It's a fundamental problem shared by all software.
- jude- 12y agoExactly. I'm (obliquely) affirming your argument that the commonly thrown-around excuse of "you don't need systemd, you just need something that implements its DBus interfaces" is a distinction without a difference.
- simoncion 12y agoAh. I largely agree that it is a distinction without a difference. However, I would argue that it's far easier for an end-user to drop in a replacement for a DBUS API implementation than it is to drop in a replacement for a C/C++ API implementation. So... there's that, I guess. :/
- icebraining 12y agoIs a system running Linux + Wine no different than Windows, just because it implements the same Win32 API? Is FreeBSD the same as Linux, since they both implement POSIX? There are many ways to implement the same APIs.
- lmm 12y agoWine is not reliable enough for mission-critical software. Nor is running a nominally POSIX-compliant program that hasn't been tested on FreeBSD. If a project claims not to hard-depend on systemd, I would not trust that unless it's actually, y'know, tested on something that isn't systemd.