Future and impact of ongoing projects in Linux world

[Xen]

Daniel Llewellyn schreef op 09-10-2016 21:17:
> On 09/10/16 19:53, Xen wrote:
>> I am pretty sure that any application that does not support GVFS
>> will not see those mounts so easily. You will have to symlink them
>> and that defeats the purpose of the system in a certain sense.
>> There is no default system that everyone can use

Well, thank you for your comments.

> You're quite right that the two incumbents don't recognise each
> other's mounting mechanisms. With the gvfs system I do successfully
> use the command-line to access the mounted filesystem, which suggests
> that KDE applications should be able to access also. I believe the
> problem you encountered is due to the daemon that gvfs-mount talks-to
> isn't running (is it called gvfsd?), which you _might_ be able to
> manually invoke in your KDE session, but I'm not sure on that - there
> might be other dependencies that need to be running (dbus-services and
> the like..?).

I personally believe KDE should easily be able to but I have this 
feeling that they don't want to use anything from the gnome camp...

Actually gvfsd was running.

I believe that there are more systems from Gnome that I would consider 
superior but at the same time GTK seems to be not very good at all. And 
I have some experience because I have coded a bit of GTK (2). I have 
heard more of this from other developers. On the other hand Cinnamon 
looks amazing and KDE just doesn't look all that good in its controls 
and the like, certainly not with Breeze.

So naturally Ubuntu (Unity) would also normally look better than KDE, I 
feel. KDE is just the most of a fully featured system that I know and 
feels more like a stable 'broad' environment that I can use. KDE feels 
more solid (even when it might not be).

> As a feature request that you could try to get implemented by the
> gnome guys you could suggest to their issue-tracker that gvfs support
> KIO-slaves. Also would be worth suggesting to the KDE guys the
> inverse, for KIO to support gvfs-mounts.

But KIO itself does not provide any mount points so that would not 
readily solve a thing unless they called gvfs-mounts to provide that, 
yes.

But I don't think they ever will.....

> I sense the best overall solution would be to unify the daemon-side of
> both KIO and gvfs into a single daemon that both desktops back-onto,
> but I wonder about how much pushback or otherwise such a unified
> effort might encounter from both camps, and others. I bags the name
> GKVFIOS and GKVFIO (hybrid nomenclature between GVFS and KIO :-p).

;-). That might be some intermediate daemon that will just provide a new 
API that both can agree to ;-).

It has to be a joint effort and not one having to use the other. And I 
still wonder whether they will like it and whether it is really a good 
effort to make. I feel a systemd approach is really a superior choice 
here if it can be had.

If you can have some system that will simply save mounts as SystemD 
services, you already have an example and a solution, although the user 
interface might not be so good (as it is with gvfs-mount and the other 
bin-utils, supposedly).

Personally I think SystemD is lower level and in that sense more 
dependable and more broad...ly available. It might not do the same 
things but... at least it is something both parties could use.

However filing feature requests is nonsensical unless the feature 
request is fully featured which means developing the idea prior to 
filing the feature request which comes down to developing the feature to 
begin with. You can't just say "Hey, I want that, can you make it?" and 
then assume everything will be alright, you know?

You have to play an active role in these things or it won't come to be 
and I seriously cannot understand how anyone can see these emails as not 
playing an active role in this thing.

Besides if you filed a random open-ended feature request it might turn 
out to be exactly what you don't want when they make it, if they make 
anything, if "they" actually exist and it is not you.

Is all I am saying.

Regards, and thanks for the help.

Kudos, Bart.