<div dir="ltr"><div>> Thanks for your detailed responses, I've had a look around your site etc<br>> but I can't see a donation email address etc?<br><br>I am curious why this idea came up :D I don't need donations for just annoying<br>people on the mailing list :-)<br><br>> In general: I'm coming from the standpoint of implementing a minimal<br>> amount of functionality around a core problem that is to be solved - the<br>> aim isn't to solve all problems or everyone's problem. In your emails<br>> you talk a lot about the bad consequences of the alternative to using<br>> shared libraries for solving (from my perspective) non-core problems -<br>> I'm saying they aren't in the scope of the program and therefore aren't<br>> to be solved (changing a program's underlying configuration store and<br>> expecting it to update as appropriate, running more than one instance<br>> and expecting configuration to be shared, etc). The use cases you<br>> describe (loads of IDEs, Firefox instances, sandboxing, application<br>> migration etc) sound very much like unusual edge cases that would be<br>> rejected (or relegated to a separate optional removable<br>> layer/implementation), with KISS.<br><br>Yes, you're right. Reasoning about what you need from an individual perspective<br>differs from reasoning about it from a global perspective. This problem exists<br>in design, in urbanism, in systems engineering, and so on... When there are<br>multiple stakeholders involve with similar, yet slightly different needs, savings<br>can be made at scale through reuse. This goes for code as well :-)<br><br>> Forgetting about my simple plugin, yes I do agree with the idea of a<br>> shared settings store when it comes to things like styles. I guess the<br>> next question is, if xfconf is portrayed as an ideal central<br>> configuration and changes manager, why do kernel programmers chose to do<br>> a similar thing (without change notification mind, theres inotify for<br>> that) through RAM-based filesystems (procfs, sysfs etc)?<br><br>Procfs is not that handy. Most files have an awkward syntax that poorly interacts<br>with C (e.g. environ, you need to parse NUL separated strings and you can't<br>figure the size of the entire file because it's a procfs file so you have to parse<br>blindly until you encounter two NULs in a row; takes a while to figure that out).<br>No atomic changes, no caching of changes, etc (e.g. GFileMonitor has a method it<br>uses to cache multiple changes to files in order to reduce the processing cost of<br>file changes for child applications). THe max size of an environ array is in<br>hundreds of megabytes on a modern Linux so you also need a logic to reason about<br>reading the file in multiple chunks if too big, and a logic to reason about whether<br>a string you're processing is truncated by your buffer size or not. Not funny at<br>all to do and I trust few CS students to do this right.<br><br>For me the KISS approach would be to provide proper functions in the system call<br>interface that have well defined and well scoped semantics, for all commonly<br>required operations, rather than let hoards of developers guess how they should<br>go about parsing complex files that violate some of the expectations of what<br>constitutes a file. ;-) Procfs is useful to provide opportunities for advanced<br>sysadmins / developers who have needs that were not anticipated by the Linux<br>developers. I personally would love to have a getenv that takes a damn PID as a<br>parameter rather than have to write awkward parsers.<br><br><br>> I'm not sure why you've picked on 'standard place for configuration' a<br>> few times, I don't have a problem with using what<br>> xfce_panel_plugin_lookup_rc_file provides. I'm not rebelling against<br>> desktop organisation.<br><br>Multiple methods of processing config = multiple code bases that need to implement<br>the same standard. Now given that our upstream GTK+ loves to break their own rules<br>and existing XDG standards, and that the most popular Xfce distro is based on an<br>upstream that equally loves to break conventions, we can expect that every now and<br>then our upstreams will change how their code works, and ours will be lagging behind.<br><br>For instance GNOME has changed how they name .desktop files. This has forced me<br>to rewrite some code (somewhere in GTK+ or Xfce, forgot) that reverse looks up<br>desktop ids from exec names, which is now much more complex. If a function had<br>been provided for this by the GLib, I would not have had to triage a bug, and then<br>patch a piece of software.<br><br>The same goes for our settings backend. The way XfceRc saves changes is not<br>compatible with the way GKeyFile works and probably not compatible with KDE's<br>backend either. So we're producing files that other DEs and apps based on other<br>toolkits may fail to process properly. By delegating XDG-related operations to our<br>upstream, we can provide better consistency and reduce our maintenance costs.<br><br></div>Yes, that means delegating control and thus taking risks.<br><div><br>> I don't know much about DBus, specifically why its needed compared to<br>> more normal alternatives (so now I know it is at least a means for<br>> broadcasting configuration changes) - I just see it as extra insecure<br>> inefficient complexity. Yes I know that DBus has been attempted to be<br>> pushed into the kernel a number of times - I read the reason for pushing<br>> it in was to get extra efficiency, but rather it is its<br>> design/implementation that is inefficient, so it was rejected.<br><br>DBus is the IPC mechanism used by nearly every Linux applications. In ten years<br>of CS there are several native IPC mechanisms I've simply never used; this is how<br>rarely they end up being better than the alternatives. Including DBus thus makes<br>sense, it serves a purpose.<br><br>> The kernel inclusion is also suspected to be an attempt to engineer<br>> insecurity, and possibly further control by RedHat?[0] Can't really<br>> comment on that as I don't have any experience here.<br><br>Haha. People come up with such funny ideas :-) <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 May 2016 at 19:42, OmegaPhil <span dir="ltr"><<a href="mailto:OmegaPhil@startmail.com" target="_blank">OmegaPhil@startmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/05/16 19:53, Steve Dodier-Lazaro wrote:<br>
> Woops, missing the first part of the novel I just wrote. This reads<br>
> *before* the previous email :D<br>
><br>
> Needless to say, don't take this email entirely to the first degree. I'm<br>
> ranting<br>
> like the moron I am, with no political correctness filter, about this<br>
> specific<br>
> topic but it should be stated I'm not targeting anyone in particular and<br>
> this<br>
> conversation can be had about pretty much every other type of software<br>
> we're using<br>
> and developing at Xfce.<br>
<br>
<br>
</span>Firstly sorry for the significant delay in responding to your mails,<br>
I've just quoted a bit of the last since theres a lot of content in the<br>
two in general.<br>
<br>
Thanks for your detailed responses, I've had a look around your site etc<br>
but I can't see a donation email address etc?<br>
<br>
<br>
In general: I'm coming from the standpoint of implementing a minimal<br>
amount of functionality around a core problem that is to be solved - the<br>
aim isn't to solve all problems or everyone's problem. In your emails<br>
you talk a lot about the bad consequences of the alternative to using<br>
shared libraries for solving (from my perspective) non-core problems -<br>
I'm saying they aren't in the scope of the program and therefore aren't<br>
to be solved (changing a program's underlying configuration store and<br>
expecting it to update as appropriate, running more than one instance<br>
and expecting configuration to be shared, etc). The use cases you<br>
describe (loads of IDEs, Firefox instances, sandboxing, application<br>
migration etc) sound very much like unusual edge cases that would be<br>
rejected (or relegated to a separate optional removable<br>
layer/implementation), with KISS.<br>
<br>
Perhaps I don't have the experience - when I see the concept of having<br>
to depend on a lot of external implementation of these non-core<br>
functionalities, I just see it as a large amount of external control<br>
embedded in my code, dragging me along with irrelevant (to the purpose<br>
of my program) changes (along with large complex alien codebases if I<br>
need to investigate a problem with them, etc).<br>
<br>
Forgetting about my simple plugin, yes I do agree with the idea of a<br>
shared settings store when it comes to things like styles. I guess the<br>
next question is, if xfconf is portrayed as an ideal central<br>
configuration and changes manager, why do kernel programmers chose to do<br>
a similar thing (without change notification mind, theres inotify for<br>
that) through RAM-based filesystems (procfs, sysfs etc)?<br>
<br>
There you have efficient access to separate blobs of information in a<br>
defined hierarchy that can be waited on for changes (and there is<br>
separation of information into multiple files so its not always a case<br>
of having to parse a large file when something changes etc).<br>
<br>
This seems to represent the UNIX/KISS philosophy (interacting with<br>
plaintext files using standard file tools/functionality).<br>
<br>
I'm not sure why you've picked on 'standard place for configuration' a<br>
few times, I don't have a problem with using what<br>
xfce_panel_plugin_lookup_rc_file provides. I'm not rebelling against<br>
desktop organisation.<br>
<br>
<br>
I don't know much about DBus, specifically why its needed compared to<br>
more normal alternatives (so now I know it is at least a means for<br>
broadcasting configuration changes) - I just see it as extra insecure<br>
inefficient complexity. Yes I know that DBus has been attempted to be<br>
pushed into the kernel a number of times - I read the reason for pushing<br>
it in was to get extra efficiency, but rather it is its<br>
design/implementation that is inefficient, so it was rejected. The<br>
kernel inclusion is also suspected to be an attempt to engineer<br>
insecurity, and possibly further control by RedHat?[0] Can't really<br>
comment on that as I don't have any experience here.<br>
<br>
<br>
0:<br>
<a href="https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/" rel="noreferrer" target="_blank">https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/</a><br>
<br>
<br>_______________________________________________<br>
Xfce4-dev mailing list<br>
<a href="mailto:Xfce4-dev@xfce.org">Xfce4-dev@xfce.org</a><br>
<a href="https://mail.xfce.org/mailman/listinfo/xfce4-dev" rel="noreferrer" target="_blank">https://mail.xfce.org/mailman/listinfo/xfce4-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div>Steve Dodier-Lazaro<br>PhD Student<br>University College London<br>Free Software Developer<br></div></div></div>
</div>