Design to "graceful degradation" when using non-universal features
Brought to you by:
insilmaril
Menu
▾
▴
#122 Design to "graceful degradation" when using non-universal features
If it is possible for an expected OS feature not to present, have a means of disabling its use so the main product can still launch. On some linux versions, vym just up and dies if it can't attach to the UNRELATED (and extraneous) "D-Bus".
I have a desktop on 1 machine (with a graphics card) and run programs on another machine with lots of CPU & diskspace. Yet vym just rolls over and dies if it can't fine D-Bus. DBus isn't required for any of vym's core features. That it should complely prevent launch is broken. It's like 'vim' that can support various language interpretters -- it can be linked with the libs 2 ways. One, link the, say Cobol lib, to the main binary so that launching vim requires Cobol to be present. Everyone runs cobol, right? cough.
Or it can use the run-time dynamic load function on such libs so that vim still runs and can do its core-function -- editing, w/o colbol being present. So only users who try to run cobol from with-in vim will be inconvenienced -- and be told that cobol support isn't present.
Same with D-Bus -- if not present, don't roll over and die, but continue w/o DBus support, so users can use the core features of vym (without having to find its source and how to disable DBus @ compile time).
Related
Discussion
The reason I mentioned graphics, is the "headless" linux machine I wanted
to run vym on, used to work with the display sent to my Win7 desktop using
'X'. At one point, DBUS was envisioned to work on split machines or cluster
machines that talk via a protected, internal network not accessible to the internet.
While the documentation mentions this, it was never implemented with the DBUS
people afraid that one wrong move could cast such negative light on the project
that it might kill it. While I tend to think he is over-reacting, I've seem
some pretty bad knee-jerk reactions to limited security problems where they
misconfigured their server, and blamed the unix software for allowing them
to shoot themselves in the foot. *ahem* Anyway, AFAIK, running the IPC over the
network doesn't work. It was my original idea w/my computer to use the Win
computer as a rendering/desktop, and the linux computer as handling pretty much
everything else, so having dbus treating my setup as 1 computer would be
ideal (it uses a Point-to-point 10G ethernet that isn't exposed to the internet.
Anyway -- even though dbus is supported on cygwin and unix, no way for them
to talk at this point. (*sigh*).
Tnx,
Astara
Related
Bugs:
#122Hm, I thought meanwhile all major Linux distribution use DBUS for IPC. That's not related to using graphics or not. Is there no DBUS at all on your machine or just no session bus available?
The former would be a packaging issue IMHO, to be solved by maintainers of your distribution. The latter I probably could catch.
Meanwhile vym uses cmake for building, if at build time no DBUS is present, it won't be compiled into vym. So basically a packaging issue.
If this is still a problem, please open a ticket at https://github.com/insilmaril/vym