Future and impact of ongoing projects in Linux world

[Xen]

Daniel Llewellyn schreef op 09-10-2016 21:37:
> On 09/10/16 20:17, Daniel Llewellyn wrote:
>> On 09/10/16 19:53, Xen wrote: 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.
> 
> Having just read your other reply to Ralf, I wanted to say that I
> don't mean to be saying "don't do the work, ask someone to do it for
> you". Filing a feature request was a suggestion for those that don't
> have the developer mindset. As you indicate you have such, I would
> revise my suggestion to opening a dialog with the two teams,
> individually, and detail your ambitions. Try to get them to assist you
> in understanding their code-bases. Fork each of the systems and
> implement the cross-polination, before asking for them to merge your
> changes when you think it's ready.
> 
> Alternatively attempt to unify the two systems (licenses permitting)
> into a single back-end and publish independently. Then send patches to
> each of the projects to switch their front-ends to use your back-end.

Of course that could be a good path forward if that was the first thing 
to do, thank you.

What I mean by that is that if you start creating a house and you talk 
about a room people may tell you how to create the room but maybe you 
are only discussing the room and you are still building the foundation 
of your house, you see?

This automount stuff is not my primary objective as of today so I won't 
be doing that but...

The first thing you do is to get your own systems working in a certain 
way. It does not help if you have food in a month if you have to be 
hungry today. So first my own systems must be in operating order in that 
sense, you know.

Then when you have rudimentary levels of support and functionality you 
start publishing these rudimentary things (or you were already doing 
so).

Then at a certain point you may find that you cannot advance in your 
functionality without going higher level and getting the cooperation of 
other systems or people that already exist. But you must first have a 
basis to start from: that rudimentary thing.

Rudimentary things require rudimentary systems so you first focus on 
understanding them and getting those basic building blocks working 
together as they should. That is why I say that high level functionality 
is not much use because /a developer can't use them/.

You can't use bits and pieces of snaps to create something else. This is 
hardly possible.

Systemd is both high and low level, annoyingly so.

And I have many different goals but as it stands you know what I've said 
is that the problem is that the user has very little focus and the 
system has a lot of it. And you must start to work across the spectrum 
to move that in the direction of the user, a single system will not 
suffice. And then you can get a more secure system because the 
administrator becomes less used than the regular user.

See for me it is more about the broader concepts than working hard to 
fix a single system in isolation. That is why I discuss this here, of 
course. Or, at least, I hope to....

Because without a deeper understanding you cannot solve anything I 
believe. And it also helps if other people also have that deeper 
understanding before you start making anything, at least in isolation, 
or at least with the idea that eventually they will turn around but you 
have never spoken to them before? That doesn't work, you know it.

So I'm not gonna be some slave to their code bases ;-). No one should, 
really, they have enough problems with it themselves already ;-). (You 
should see what madness the plasma developers have to deal with -- (I 
was on their list once)) -- and really I just feel everyone should just 
do their own thing and that requires (being able to make use of) 
building blocks. But if the bigger parties make it so that the building 
blocks disappear, we have a problem.

And that is also perhaps why I am arguing here today: don't turn 
everything into high-level things that have no components.