subject:"Re\: Future and impact of ongoing projects in Linux world"


Daniel Llewellyn schreef op 09-10-2016 21:43:

On 09/10/16 20:35, Xen wrote:

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.


Well, I would love a SystemD-based user-level mounting support as you
suggest, the problem is that the BSD projects have all suggested that
they will not or cannot implement anything SystemD, partly due to it's
integral nature with the Linux kernel. Unfortunately this means that
any implementation of user-mounting will either not work at all on BSD
or will need to be independent of SystemD if you desire it to be
accepted by BSD, which _may_ (I don't know for sure) be requisite for
acceptance into Gnome and/or KDE..


I think it's still the only thing I can do myself.

I have never used BSD so it is no worry to me from the beginning at 
least, and I just want something that works for me, as well, I am sure 
you can understand that ;-).


I just believe that creating a model is foremost. If the model is right, 
the solutions will follow. What I mean is that if you create something 
that is modular enough, other people can recreate it. I know SystemD is 
not very modular in that sense... it is not like you can take many 
pieces out, right. I also object to some of their command line 
interfaces in that sense, but... you know, you can't always have 
everything the way you want and you sometimes just have to go with what 
is available and what is functional and achievable, you know.


I don't really even know what BSD has to do with a user-level GUI, 
but...


I'm not aware of BSD being more popular than 1% of Linux? I could be 
wrong...


Sometimes you just have to create something that works and if the model 
is right you can expand it to something else...


The autofs developer... has also not been unkind... to me, but autofs 
regularly failed for me while using it so I stepped away from it. And 
that leaves libpam_mount which works reasonably well albeit a bit rough. 
So you see, I have been around a bit :p.


Even discovered a smb mounting bug (or limitation) in which having the 
same hashed password for different users creates a problem (if the 
usernames are identical, but the domains aren't). If you want to know 
what I've been doing... I've just been patching smb to have a new option 
for mounting that works with my system... so I am just doing 
groundwork... not anything big in that sense...


Sorry about that, you know. But the big things can wait until the 
smaller pieces are in place, I feel. One can perform a hundred smaller 
operations in the same time it would take to take on 1 big project. Even 
much more than that...


So we do the groundwork first, is what we do.

Regards ;-).

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


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.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/16 20:35, Xen wrote:
> 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.

Well, I would love a SystemD-based user-level mounting support as you
suggest, the problem is that the BSD projects have all suggested that
they will not or cannot implement anything SystemD, partly due to it's
integral nature with the Linux kernel. Unfortunately this means that
any implementation of user-mounting will either not work at all on BSD
or will need to be independent of SystemD if you desire it to be
accepted by BSD, which _may_ (I don't know for sure) be requisite for
acceptance into Gnome and/or KDE..
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX+p3iAAoJEFx8XrpDpVlRBFoH/2NqSIL/5H8uI2Qj62BOO6nP
TFgVrPyue0EMEts2xNDMf+9QRKljfskCWN2/k2IBE/+NLNLyWAkwMLE+L7g4SRm/
vGrngRSFuE3CQInmHBe7Fp3YVfZFnrXHY5kgStASuxxFkpiNx3aZGsBOI8EB/snU
NnRhGHWJzQZYHSq66zhojDQm6Sy/t7fi9+5fEz0lFBa5RprUyPbMfQgLestmUfXP
UMtd/n3bjOs3wrKiyWpioS+G5KV4AZtGaRvgUW3UXGLFd31XlcGrhVbbOQhqbbx/
pyQw++sT8XBgBWwNlIeaJyMLy3D8F80NEzUNw8CtXV819YTshEuTX4RJyJG+Hdg=
=UotU
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX+pxgAAoJEFx8XrpDpVlR4RQIAJ9+nSYsJfezHTXwJdexZ19a
aaFzpSKfSLrvUoB+eEZqx4vSEhUYB5W6/5wn8TT8BOeRY2f4s+EFnLbUKYN7PkPy
an3ykfO2DsYRhOEX9GPbaTnhRI24FrD54B9ULHKlDwH4xECw+cXiZbLg1USsqAkF
aXhZ8mZ211E7K4nH04gjwFJxLYENxaHMOG7IHOaPL7tqe6jfxntmt7N+F93hlWW1
MsqBNIXYJIR+QhtO2x/+SChybCHJRqUzHA8msQMeg3v1WMbCRTDgAa8TSEh5EXmt
kQFYwfqUMDcnIAyyP8TTwhZHV5e7m/rIBoTvTKWt7L9s7eAsjMypV7JuPvh44xY=
=YTEe
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


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.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 09-10-2016 20:12:

Hi,

this time I read your complete mail, I just didn't watch the video.

A very last reply from me.

If you notice, that low level software requires improvement, you could
assume that this isn't something Ubuntu developers could change. A
feature request send to upstream makes more sense, than a discussion
about missing functionality on an Ubuntu mailing list.


There is no upstream for what you want, idiot. You will have to create 
it yourself. Step out of that mode please.


The only ones who could want any kind of functionality like this are 
feature-rich environments like Ubuntu. This is precisely the place to 
discuss such things.


It has no place on sometyhing like Debian, for instance, for the most 
part. Unless you have already created something that works, then you can 
show it to them.



If we all would agree with you, nothing would change. The one who feels
the need for a feature request needs to file one. Why should I file a
feature request for something I don't want? No answer required, it's
just a rhetorical question, I likely will mark this thread a spam.


You seriously cannot step out of this lazy attitude of yours. I don't 
request features, I create them.


You are telling me to do stuff. Apparently you have an interest then in 
seeing it happen. Oh but you don't, so all of your remarks were 
insincere, as I thought they were. You don't want it, but you're telling 
me to create it. No, you're not, you're sending me into the woods so 
I'll never create it, if I follow your advice. You are insincere to 
begin with and you are insincere at the end, trying to instill doubt in 
other people using your "cheap rhetorical tricks" (I would call them 
tactics) as you've put so well (but perhaps mistakenly, because you 
accuse yourself with these words, they are not coming from me (not even 
once, I merely repeated your words without quotes there)). You don't 
have the mindset of a developer at all, so what are you even doing here?


Developers don't file feature requests. They create them. I honestly 
can't understand how anyone could have an attitude like you. Letting 
other people do your work for you. And then blaming me with such 
sentiments. Remarkable.


I just hope that everyone understands that I am not asking anyone to do 
work for me. I am merely discussing things, but discussion is often seen 
as a "feature request" and these people know only two modes of 
operation: not do anything, or beg for things.


So when you complain about the status quo they see it as begging and not 
as a way to move forward with what you want to create. And that's all I 
can say here. And I am sorry to offend, but a huge amount of energy in 
Linux is just expended at stopping people who want to create something 
great. Everything you want to do you will find jealous people who say 
you can't, or should not do it. Or should be doing something else that 
would render you compeletely ineffective or even dysfunctional. Because 
filing requests for stuff is simply not a functional way of achieving 
stuff, I hope people can understand.


And I am spending time debating people who only try to stop what I am 
doing. And I could also be spending that time on functional stuff, but 
many people are only interested in bringing other people down than doing 
anything good. Criticising people for what they are doing, instead for 
what they are not doing.


And it doesn't help much if everything you do is getting criticised. 
Meanwhile these same people never come up with anything else, they only 
break down what you do, but do not come up with any alternative that is 
actually creative and advancing in the slightest sense, no, you must be 
happy with what already is.


And then they propose the least-effective and least-creative form of 
moving forward that is "filing feature requests". I am sorry, but that 
just blew my hat off. All slaves to the wage, I guess...?


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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

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..?).

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.

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).
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX+pelAAoJEFx8XrpDpVlRL88H/R8eYeiHgwPzysRUC7l+E1ZX
NyTwGKr6WLcaCs2wryayGekjaWYCFGisL8AJBi87VbaGZncTfs2BuMjTIM7AG1St
wMRYky6PMr/trhyXk0PrK4CZY8BGFB65JvINpec1IBNF4v39UesBFsXBGLDuSeJ5
zxyhVKtJB0EodZS+b6ffQqSsETR5mDcBEG4SlTPaTnDpc3s36rCNEmD8Hq8ncU+y
H/arNEd9M/kamkL1jrd4FTbYe+6ks2vkGA6ADini9paXJXsO+6ZA8jT4sVZiAArX
eWIXV+MGCbvjno0YDfJm/Wt8SEaa2nWtWFizxQ7TjpRV4FphhqINjFqBmDqqmmA=
=t6NQ
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

Daniel Llewellyn schreef op 09-10-2016 19:39:

OK, I'll bite..

On 09/10/16 18:26, Xen wrote:

Daniel Llewellyn schreef op 09-10-2016 19:07: These are not
consistently mounted, is what I was talking about. You will have to
go to that mount point (browse to that network share) every time
you reboot the system. Every time you re-login to the system,
maybe even.

To replicate my mount at boot I can open "startup programs" from the
dash and add an entry with the command-line:

gvfs-mount smb://freenas/videos

Moreover, try to answer me what actual filesystem path these mounts
are getting, if you want.

Sure, it's at:

/run/user/1000/gvfs/smb-share:server=freenas,share=videos

Well thank you, I am reading up on these things.

gvfs-mount doesn't work on my Kubuntu system:

Error mounting location: volume doesn't implement mount

Well actually now it does work. But I get no mountpoint. I have no way
to know how to get this running at this point. I just installed Nemo
from Cinnamon. Should do the same thing. And it does mount but not with
a mount point, so I don't know why.

Great that you can add those autostart mounts, I must say.

Since, I've been googling, can you also answer whether today in every
program you are capable of accessing those mounts? I mean programs like
Chrome and Firefox. Do they see the mount in the available list of
volumes in their left-pane (or whatever) file-browser file-open dialog?

Point being I did experience your mounts in Ubuntu when I ran it (just
not persistent) but to me the command lines that were opened (the full
path) was much too long (when opening it in Terminal) making many
actions from the command line near impossible to really do well (because
you hardly have space for typing your commands) and of course you can
link it to e.g. ~/mounts but I always opened a terminal from the
menu/GUI/dialog.

So that mount location is for me a no-go, in essence.

Also the mounts from KDE would not show up in Gnome applications and
vice versa (some KDE "place" will not be visible to a Gnome application,
and some Gnome "gvfs mount" will then not be visible to KDE
applications, or something like that).

Stuff mounted in Nemo is definitely not visible in Dolphin and this is
also just one reason why I consider GUI-based solutions not very
good. GVFS is no GUI but it is related to Gnome of course. And "KIO" is
no GUI either but it is related to KDE.

Basically every KDE application will not see those mounts.

KDE has an application called SMB4K I just discovered. Never knew about
it. It is a feature-rich Network Neighbourhood browser, but it just
fails to work for me due to a permission error in /var/samba/something
and it just doesn't work out of the box for me. It allows you to mount
stuff easily in ~/smb4k.

People are apparently not happy about the new direction of gvfs:

"This whole thing worked a lot better when the gvfs mount point was
within the users home directory but it was changed because developers
like to change things until they break." (2013)

"In the GTK/Gnome world you have to waste your life typing arcane
commands into terminal trying desperately to get the same functionality.
Yes, I am aware of 'gigolo' but due to the fundamental design flaws of
GTK/Gnome (GVFS/GIO) it will not allow the ease of use and transparency
expected.

Mark my words." (some KDE person, 2013, same thread)

"In Gnomelandia when Nautilus or any other file manager accesses a
remote share it creates an actual mount point automatically and until
this new buggy gvfs was implemented all a user had to do was access that
mount point ( ~/.gvfs ) for non-compliant applications." -- very
convenient and I apologize, because I am coming to this from a KDE
perspective and on my Mint install the network browser doesn't work at
all. Can you really blame me that I think it doesn't work anywhere?

KDE does not have default mountable shares and you have to use that
SMB4K that doesn't work out of the box on my system and I have no
special system in that regard, just Kubuntu 16.04 (oops?).

I mean this was a convenient post:
https://colan.consulting/blog/how-mount-windows-file-share-ubuntu-1304

But I *personally* do not have this functionality that you mention. :/.
You are more lucky than I am, in a sense.

Also it is annoying as hell if those mount points are not available but
you can fix that with symlinks and bookmarks, I guess.

Personally at this point I am using:

mountpoint="/nas/home" fstype="cifs"
options="user,credentials=/home/%(USER)/.samba-creds,uid=%(USER),gid=nas,forcegid,file_mode=0644,dir_mode=0755"
/>

mountpoint="/nas/media" fstype="cifs"
options="user,credentials=/home/%(USER)/.samba-creds,uid=%(USER),gid=nas,forceuid,forcegid,file_mode=0640,dir_mode=0750"
/>

Just a small part of it and not that easy to set up as you can. But
autofs consistently fails me at times and now I have these locations
available for myself:

/nas/home

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Ralf Mardorf

Hi,

this time I read your complete mail, I just didn't watch the video.

A very last reply from me.

If you notice, that low level software requires improvement, you could
assume that this isn't something Ubuntu developers could change. A
feature request send to upstream makes more sense, than a discussion
about missing functionality on an Ubuntu mailing list.

If we all would agree with you, nothing would change. The one who feels
the need for a feature request needs to file one. Why should I file a
feature request for something I don't want? No answer required, it's
just a rhetorical question, I likely will mark this thread a spam.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OK, I'll bite..

On 09/10/16 18:26, Xen wrote:
> Daniel Llewellyn schreef op 09-10-2016 19:07: These are not
> consistently mounted, is what I was talking about. You will have to
> go to that mount point (browse to that network share) every time
> you reboot the system. Every time you re-login to the system,
> maybe even.

To replicate my mount at boot I can open "startup programs" from the
dash and add an entry with the command-line:

gvfs-mount smb://freenas/videos

> Moreover, try to answer me what actual filesystem path these mounts
> are getting, if you want.

Sure, it's at:

/run/user/1000/gvfs/smb-share:server=freenas,share=videos
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX+oDoAAoJEFx8XrpDpVlRZ1kH/2kYEEWJN4TXHVQz7mbtmRB5
oh31N6AExCilrmrj1zEeZiMHw+uxaUz8qo5drlC+poR4NY99wRspxrXNvyeSZEUd
EzihveHQ9N8ramVcETeizkRymwrqxThstiCsB97Kin7Fr45oNXsOKwunJ9Gsy9Pp
y/WR6+nBRwRrg58riyqXdoBQbgGzjJm3BR1rtWSeUEMcnHakxpmh/WmkoCUBOjd+
FyZ+EFvgQVH2PA1MgI0btCfVJFy2kBUzpxDB2xFsweE7Qqi8mMl545K9KalKp3Dk
WLMeDbUjMU8rUxtBWvZIbYjZBAbkFftHaU/uWwrh8q9Svb76hztHnVyV19BLuHQ=
=z0qp
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Daniel Llewellyn schreef op 09-10-2016 19:07:

On 09/10/16 17:32, Xen wrote:

The same is true with mounting samba shares, it is not possible
with any degree of ease, today. Of course, I want to work on it,
but I can't do everything alone, or at the same time.


I'll just leave this here (copy+paste both lines of the link to see
the image/video):

https://www.dropbox.com/s/mgilyc6vlqyhnq4/Peek%202016-10-09%2018-00.gif?
dl=0


These are not consistently mounted, is what I was talking about. You 
will have to go to that mount point (browse to that network share) every 
time you reboot the system. Every time you re-login to the system, maybe 
even.


Moreover, try to answer me what actual filesystem path these mounts are 
getting, if you want.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 09/10/16 17:32, Xen wrote:
> The same is true with mounting samba shares, it is not possible
> with any degree of ease, today. Of course, I want to work on it,
> but I can't do everything alone, or at the same time.

I'll just leave this here (copy+paste both lines of the link to see
the image/video):

https://www.dropbox.com/s/mgilyc6vlqyhnq4/Peek%202016-10-09%2018-00.gif?
dl=0
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJX+nlKAAoJEFx8XrpDpVlR69UH/2wncQTucL8NYS6dLRXV19XT
1MeAuFv8TqfDjnje2bHOBV6DGYmzTBbqpevtMKW4bLeK41upM3c2xWMXrm5qxZhI
muWJWShdu4PPUwbGYxp8EhK6DW69yujkG01uis/5HP/5LWWsS8ZClAPKNZbIwebD
z28vHVPazCWJguwGQtj6pHKs34zm6nH9WCublU486q398QTI8SoMXGxjORf/wxRu
aF3TYb+wP2T7BGcr2G36qYe+vYipC/UEFm+WJ74ow51pJp9L4RLn/B6PZyRR0HWA
hCL8VQjDfO6iSBDvM7YXsRzziavok4mADPXdD0+j6hvl+d5tt6LCkykwWV5DAbk=
=vVUq
-END PGP SIGNATURE-

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Colin Law schreef op 09-10-2016 16:48:

On 9 October 2016 at 15:43, Xen  wrote:

Colin Law schreef op 09-10-2016 14:38:


On 9 October 2016 at 12:56, Xen  wrote:


Colin Law schreef op 09-10-2016 9:28:


...
I was not commenting on any particular topic, merely pointing out 
that

that Ralf (I think) said there are some things that Linux "does not
allow" and you answered this with a post referring to things that
Linux "can't" do and the two things are not the same. I also stated
that things that Linux will not allow are generally security 
related.


Is any of that untrue?




You might as well state that the sun is not green and that might 
also not

be
untrue. But the question is whether that is relevant or related or
whether
it is a showstopper.



That is one question, but as I said it was not my point.  I was 
merely

pointing out that you had misread or misinterpreted the earlier post.
Nothing more or less than that.



And that is simply not true. And apparently you are arguing for the 
sake of

arguing.


In what way is it not true, it was my first post on this thread and
all I said was:

"I think there is a difference between *can't* meaning is not able to
and *won't allow* meaning there is something specifically stopping
that from happening.  The *won't allow* features are generally for
security reasons."


I've responded to this to Ralf, but...

I had said Windows can do something that is impossible in Linux.

Ralf responded by saying that it is allowed in Windows but not in Linux 
and that that would probably be for a good reason, or something of the 
kind.


So it was Ralf who muddled the waters between "can" and "be allowed to 
do" and not me.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Colin Law

On 9 October 2016 at 15:43, Xen  wrote:
> Colin Law schreef op 09-10-2016 14:38:
>>
>> On 9 October 2016 at 12:56, Xen  wrote:
>>>
>>> Colin Law schreef op 09-10-2016 9:28:

 ...
 I was not commenting on any particular topic, merely pointing out that
 that Ralf (I think) said there are some things that Linux "does not
 allow" and you answered this with a post referring to things that
 Linux "can't" do and the two things are not the same. I also stated
 that things that Linux will not allow are generally security related.

 Is any of that untrue?
>>>
>>>
>>>
>>> You might as well state that the sun is not green and that might also not
>>> be
>>> untrue. But the question is whether that is relevant or related or
>>> whether
>>> it is a showstopper.
>>
>>
>> That is one question, but as I said it was not my point.  I was merely
>> pointing out that you had misread or misinterpreted the earlier post.
>> Nothing more or less than that.
>
>
> And that is simply not true. And apparently you are arguing for the sake of
> arguing.

In what way is it not true, it was my first post on this thread and
all I said was:

"I think there is a difference between *can't* meaning is not able to
and *won't allow* meaning there is something specifically stopping
that from happening.  The *won't allow* features are generally for
security reasons."

Colin

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Colin Law schreef op 09-10-2016 14:38:

On 9 October 2016 at 12:56, Xen  wrote:

Colin Law schreef op 09-10-2016 9:28:

...
I was not commenting on any particular topic, merely pointing out 
that

that Ralf (I think) said there are some things that Linux "does not
allow" and you answered this with a post referring to things that
Linux "can't" do and the two things are not the same. I also stated
that things that Linux will not allow are generally security related.

Is any of that untrue?



You might as well state that the sun is not green and that might also 
not be
untrue. But the question is whether that is relevant or related or 
whether

it is a showstopper.


That is one question, but as I said it was not my point.  I was merely
pointing out that you had misread or misinterpreted the earlier post.
Nothing more or less than that.


And that is simply not true. And apparently you are arguing for the sake 
of arguing.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Ralf Mardorf

On Sun, 9 Oct 2016 15:05:59 +0200, Ralf Mardorf wrote:
>Users by default cannot use sudo to get user privileges
>for good reasons.  ^
^superuser ;)

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Ralf Mardorf

I didn't read all your trolling, however, what I already read is
simply stupid. Users by default cannot use sudo to get user privileges
for good reasons.  The Ubuntu default should be, that just the first
user, with the ID 1000, is able to get root privileges by sudo. On a
multi-user system it's not wanted, that everybody is allowed to mount
what ever she wants. Yes, some users cannot access what they want, due
to security reasons.
Regarding your argument that by accident somebody could wipe out a Linux
install, there are several security mechanisms to prevent users to
delete important things. One is that users cannot use sudo to get root
privileges, but even a superuser has levels of protection, for example
to mount read only, to set the immutable bit, not to use rm -r, but
instead rm -I files* and rmdir or e.g. unlink instead of rm to remove a
link. You describe Windows user typical behaviour without
self-responsibility. For the averaged Ubuntu desktop PC user on a
single-user environment, by default this user could use sudo, gksudu.
There are several solutions to realise what you want, wide spread is
usage of e.g. pkexec.

Indeed, some things cannot be done with Linux, but could be done using
other operating systems. Usually this is related to nieces that require
much money and manpower for the development. For those nieces there
sometimes is non-free software for Linux available, too and sometimes
FLOSS coders simply need more time, due to the lack of manpower and
money.

If you need something Linux doesn't provide, than either get your hands
dirty or use another OS that already provides what you need.

I'm even not against adopting something good from another OS, I'm not
against Windows. I'm against half-truth and complains that others
should get their hands dirty, to fulfil your needs.

Even for my taste the DEs you mentioned aren't good. Openbox fits to my
needs, so I don't care about e.g. KDE.

You claim that Linux doesn't fit to your needs, but Windows does. If I
need a knife, I don't use a fork. Why do you use the OS that doesn't
fit to your needs, if there's another OS that does?

Apart from this, you could recommend that Ubuntu should consider to
provide other defaults, but actually you mentioned that already the low
level of Linux (user space? or the kernel?) needs radical improvements.

Indeed every technology needs improvements, but radical changes to
provide the same, as is already provided by another operating system,
that is known for its issues, aren't improvements.

I decided to use Linux in the first palace (I didn't migrate from
Windows) because Linux is the way it is. I also had and have critic
against Linux. Some things perhaps should be adopted from proprietary
operating systems. A lot of those already were adopted and indeed,
people who were hostile to me, now prefer those changes, too. OTOH some
changes other like, are a PITA to me. Linux is community driven.

Why don't you file feature requests to upstream and the Ubuntu bug
tracker? Insinuating that people who discussed with you, would just use
cheap rhetorical tricks, to stop you, is a bare lie.

You repeat yourself again and again, seemingly not many people agree
with your opinion, so you seem to have a problem and to solve this you
don't provide something useful. Could you post links to the feature
requests? To file feature requests doesn't require to provide patches,
so everybody could do this. Sure, KDE, GNOME etc. don't like to become
Windows clones, but you could file feature requests to the underlying
low level software you criticize.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Colin Law

On 9 October 2016 at 12:56, Xen  wrote:
> Colin Law schreef op 09-10-2016 9:28:
>> ...
>> I was not commenting on any particular topic, merely pointing out that
>> that Ralf (I think) said there are some things that Linux "does not
>> allow" and you answered this with a post referring to things that
>> Linux "can't" do and the two things are not the same. I also stated
>> that things that Linux will not allow are generally security related.
>>
>> Is any of that untrue?
>
>
> You might as well state that the sun is not green and that might also not be
> untrue. But the question is whether that is relevant or related or whether
> it is a showstopper.

That is one question, but as I said it was not my point.  I was merely
pointing out that you had misread or misinterpreted the earlier post.
Nothing more or less than that.

Colin

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Colin Law schreef op 09-10-2016 9:28:

On 8 October 2016 at 23:58, Xen  wrote:

Colin Law schreef op 08-10-2016 18:29:


On 8 October 2016 at 17:21, Xen  wrote:


Ralf Mardorf schreef op 06-10-2016 12:42:



Just a very laste note.

On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:



>> In Windows

Yes you conveniently break off my statement but (I had to look for 
it)
it was about something that has *nothing* to do with security as 
it

dealth with network shares.




Yes, you mentioned Windows allows to do this and that, but Linux
doesn't, so I pointed out, that Windows is insecure and Linux 
isn't. I
assume causality. There are reasons that Linux does work different 
to

Windows.




And so whenever Linux can't do something, it is for security? Don't 
make

me
laugh.



I think there is a difference between *can't* meaning is not able to
and *won't allow* meaning there is something specifically stopping
that from happening.  The *won't allow* features are generally for
security reasons.



A root user also cannot do the things just mentioned.

The required software does not exist, for the most part.

There are also no security considerations whatsoever pertaining to the 
local
system regarding the mounting of remote network shares on a user 
supplied

home directory or equivalent. It is utter bull. You can make such
generalized statements all you want but I hear nothing that actually
addresses the topic.


I was not commenting on any particular topic, merely pointing out that
that Ralf (I think) said there are some things that Linux "does not
allow" and you answered this with a post referring to things that
Linux "can't" do and the two things are not the same. I also stated
that things that Linux will not allow are generally security related.

Is any of that untrue?


You might as well state that the sun is not green and that might also 
not be untrue. But the question is whether that is relevant or related 
or whether it is a showstopper.


These generalized statements are only meant to instill doubt in people 
as to the validity of what has just been said.


Someone says "Linux can still not do this thing" and someone else says 
"Linux is not Windows" as if that answers the thing.


If this topic at hand has *nothing* to do with security, then mentioning 
security as a reason for certain features not to exist, is not a valid 
thing to mention at all. It merely makes people believ "Oh, that's why, 
I better stop complaining, there are good reasons for this." No, there 
aren't. That was not valid.


Of course, the question between what a user is allowed to do (no gray 
area) and what an admin is allowed to do, IS a security related 
question. But consistently, current, we find that even when security is 
*not* at play, we still cannot do a certain thing. After all, something 
that is not possible quickly becomes possible when you use sudo. So why 
can't we?


The answer lies in the fact that many system settings are system-wide 
and that there is barely any infrastructure to keep settings per user. 
That is what I had wanted to mention... and the example of mounting 
personal network resources is actually something that has no reason 
whatsoever as to why it cannot be done with a setuid program in complete 
safety as the setuid program can simply check for user permissions 
before mounting. The mount program does the same: when it is in fstab, 
it is allowed, but when it is not in fstab, it is suddenly not allowed. 
That doesn't make much sense, particularly if we were to be talking 
about a mount point owned by the user, and when there are not actually 
any system resources at play internally in the system, that are at risk 
of being accessed (and perverted or destroyed). User mounting fails when 
the user does not have access (write access) to the mount point. That 
could be the same for network mounts, you know.


Dolphin et. al. already can access remote shares, they just cannot mount 
them. There is the ability to automatically mount stuff in 
/media/user/*, but this is a managed infrastructure where the user can't 
write, the user directory is actually owned by root.


It is also not a very convenient place to access, these days. With mount 
namepaces we could easily have per-user mount points. But the point was, 
before I started editing this, that the /media structure is not actually 
user-editable or user-configurable. There is no place wherever that can 
remember these things, unless it was in the file manager, but that is 
not a good place to remember anything "system wide" or even "user wide". 
We can create high level solutions to these problems but where does that 
leave the non-GUI user?


Any good solution is going to have to be a non-GUI solution in the first 
place, that can then be managed by a GUI.


And the only facility that is needed to begin with is to mount network 
shares by a user without any root rights to a directory owned or

Re: Future and impact of ongoing projects in Linux world

2016-10-09 Thread Colin Law

On 8 October 2016 at 23:58, Xen  wrote:
> Colin Law schreef op 08-10-2016 18:29:
>>
>> On 8 October 2016 at 17:21, Xen  wrote:
>>>
>>> Ralf Mardorf schreef op 06-10-2016 12:42:


 Just a very laste note.

 On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:
>
>
> >> In Windows
>
> Yes you conveniently break off my statement but (I had to look for it)
> it was about something that has *nothing* to do with security as it
> dealth with network shares.



 Yes, you mentioned Windows allows to do this and that, but Linux
 doesn't, so I pointed out, that Windows is insecure and Linux isn't. I
 assume causality. There are reasons that Linux does work different to
 Windows.
>>>
>>>
>>>
>>> And so whenever Linux can't do something, it is for security? Don't make
>>> me
>>> laugh.
>>
>>
>> I think there is a difference between *can't* meaning is not able to
>> and *won't allow* meaning there is something specifically stopping
>> that from happening.  The *won't allow* features are generally for
>> security reasons.
>
>
> A root user also cannot do the things just mentioned.
>
> The required software does not exist, for the most part.
>
> There are also no security considerations whatsoever pertaining to the local
> system regarding the mounting of remote network shares on a user supplied
> home directory or equivalent. It is utter bull. You can make such
> generalized statements all you want but I hear nothing that actually
> addresses the topic.

I was not commenting on any particular topic, merely pointing out that
that Ralf (I think) said there are some things that Linux "does not
allow" and you answered this with a post referring to things that
Linux "can't" do and the two things are not the same. I also stated
that things that Linux will not allow are generally security related.

Is any of that untrue?

Colin

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-08 Thread Xen


Colin Law schreef op 08-10-2016 18:29:

On 8 October 2016 at 17:21, Xen  wrote:

Ralf Mardorf schreef op 06-10-2016 12:42:


Just a very laste note.

On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:


>> In Windows

Yes you conveniently break off my statement but (I had to look for 
it)

it was about something that has *nothing* to do with security as it
dealth with network shares.



Yes, you mentioned Windows allows to do this and that, but Linux
doesn't, so I pointed out, that Windows is insecure and Linux isn't. 
I

assume causality. There are reasons that Linux does work different to
Windows.



And so whenever Linux can't do something, it is for security? Don't 
make me

laugh.


I think there is a difference between *can't* meaning is not able to
and *won't allow* meaning there is something specifically stopping
that from happening.  The *won't allow* features are generally for
security reasons.


A root user also cannot do the things just mentioned.

The required software does not exist, for the most part.

There are also no security considerations whatsoever pertaining to the 
local system regarding the mounting of remote network shares on a user 
supplied home directory or equivalent. It is utter bull. You can make 
such generalized statements all you want but I hear nothing that 
actually addresses the topic. The infrastructure to do these things 
easily does not exist, not even if you supply a root or sudo password. 
That is simple fact. There are many things you can do after supplying a 
root or sudo password, including wiping the filesystem clean, and these 
are also not prevented for 'security reasons'.


We are 2016 and we still cannot mount samba shares easily. And when you 
mention this everyone that doesn't matter tries to wiggle out from under 
your gaze and pretends there are very good reasons why this is so.


I wish people would just stop lying about Linux so some actual work 
could actually be done. Every problem that is not acknowledged is also 
not solved. And what do we solve instead? Non-problems for the most 
part.


Because non-problems won't offend anyone if they are being addressed. No 
one's ego is harmed when you don't say something is wrong. Or not wrong, 
whatever you want. You will find "improvements" left and right that are 
actually detrimental and nothing much is advancing. The services we have 
today cannot really do more than those of the past. SystemD makes stuff 
easier but previously this functionality did also exist. Hacking around 
Linux was a lot easier in the past, I believe. Don't count my word for 
everthing but complexity has gone up, not down. Unity is not really a 
great success from my point of view and it is worse than Cinnamon that 
has much less resources to go at it. Cinnamon in the meantime also makes 
improvements that are detriments, such as reversing all "yes/no" buttons 
and "okay/cancel" buttons in their order, which just messes up your mind 
completely.


KDE does everything but the right thing and of all the window-switchers 
none suffices. Until you edit the "large icons" theme so it becomes the 
"medium icons" theme and suddenly you have something that is actually 
pleasing to use. Why they supply big icons (that are too large) and 
small icons (that are too small) but no medium icons in between (that 
would actually work) is beyond me.


Constantly trying to invent new stuff when it is not necessary. 
Constantly trying to be "different" from the main protagonists but there 
is no reason to. Cinnamon does so well regardless because many choices 
are just obvious: Cinnamon /does/ have a medium icon Window Switcher 
that just works.


Something that doesn't require any configuration and works out of the 
box in a nice style. Why people constantly try to come up with new ideas 
that then subsequently do not even work, is beyond me. Just in order to 
be different... Just so you can claim you are "not windows"? I don't 
know...


Windows makes it convenient, so you make it inconvenient.
Windows makes it insecure, so you make it secure.

Everything in response to something else, reactionary.

There is not actually a reason to base yourself on something else, you 
can take yourself as your own point of reference and only try to be 
better than what you were before. You can simply create what you want 
and do not have to look at something else to claim you don't want to be 
that.


I must say I applaud Ubuntu selling paid apps though and I think that is 
something Linux needs. And pardon this bad writing, once more.


Regards.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-08 Thread Colin Law

On 8 October 2016 at 17:21, Xen  wrote:
> Ralf Mardorf schreef op 06-10-2016 12:42:
>>
>> Just a very laste note.
>>
>> On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:
>>>
>>> >> In Windows
>>>
>>> Yes you conveniently break off my statement but (I had to look for it)
>>> it was about something that has *nothing* to do with security as it
>>> dealth with network shares.
>>
>>
>> Yes, you mentioned Windows allows to do this and that, but Linux
>> doesn't, so I pointed out, that Windows is insecure and Linux isn't. I
>> assume causality. There are reasons that Linux does work different to
>> Windows.
>
>
> And so whenever Linux can't do something, it is for security? Don't make me
> laugh.

I think there is a difference between *can't* meaning is not able to
and *won't allow* meaning there is something specifically stopping
that from happening.  The *won't allow* features are generally for
security reasons.

Colin

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-08 Thread Xen


Ralf Mardorf schreef op 06-10-2016 12:42:

Just a very laste note.

On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:

>> In Windows

Yes you conveniently break off my statement but (I had to look for it)
it was about something that has *nothing* to do with security as it
dealth with network shares.


Yes, you mentioned Windows allows to do this and that, but Linux
doesn't, so I pointed out, that Windows is insecure and Linux isn't. I
assume causality. There are reasons that Linux does work different to
Windows.


And so whenever Linux can't do something, it is for security? Don't make 
me laugh.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-06 Thread Xen


Brendan Perrine schreef op 06-10-2016 23:54:

On Wed, 05 Oct 2016 14:49:21 +0200
Xen  wrote:


might not even be a problem.

I honestly wonder why you need to run programs off a usb stick. I
remember even when I was a windows users thinking why do I need that.
I have run entire installed systems off an external hard drive but not
one program.


http://portableapps.com

You can basically install thousands of programs into an encrypted 
container if you want and place it on usb stick.


Every program that is available for free basically has a portable 
edition.


This means that instantly your email, for example, is not only portable, 
but also secure. You have your entire work environment on a stick 
without requiring it to be a complete system. Hence it is a plug-in 
thing that you can plug into your computer and get started. Then you 
take it with you to someone else's computer and get started. It's that 
easy.


This doesn't have to be on a stick, but it can be an internal harddrive 
partition as well, or some external harddisk if you want. Then you just 
sync the internal partition to a stick and you have a copy to go if you 
want. Mostly for me it was about data, not applications, on the stick, 
but I had the applications inside a crypt container. The kinds of 
applications that keep their own database then also have the database 
inside the container. It's a completely localized version of everything 
whereas in Linux mostly everything is always dispersed across the 
system. That's all. The only 'downside' is that windows keeps traces of 
files you access and folder locations you access in some registry 
location. You'd really have to constantly wipe that clean, 
automatically. But apart from that, you can just put a hidden volume 
inside the crypt container and put other junk that you also use (or a 
copy of it) onto the outer volume.


A pretty feel-good system I must say. But anyway.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-06 Thread Brendan Perrine

On Wed, 05 Oct 2016 14:49:21 +0200
Xen  wrote:

> might not even be a problem.
I honestly wonder why you need to run programs off a usb stick. I remember even 
when I was a windows users thinking why do I need that. I have run entire 
installed systems off an external hard drive but not one program. 
-- 
Brendan Perrine 

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-06 Thread Xen

Colin Watson schreef op 05-10-2016 21:44:

On Wed, Oct 05, 2016 at 04:23:38PM +0200, Xen wrote:

Oliver Grawert schreef op 05-10-2016 14:41:
>along with that click packages are user packages and being used in
>ubuntu products on sale since 2015 (snaps will replace them
>eventually).

That just means a user can install them, not that they are installed
specifically for a user?

Not so; click packages may be installed (technically, "registered")
specifically for one or more users.  The process is mediated by a 
system

facility, certainly, but it can be per-user.  (It's also possible to
register them for use by all users, which is roughly equivalent to a
system-wide installation.)

I understand that there can be good reasons for this yes.

The reason for it to be mediated by a system facility was so that ten
users all installing the same click package don't end up using ten 
times

the storage.  Not very interesting on a single-user phone, but
potentially interesting on e.g. a multi-user tablet and would have been
pretty important if click packages had ever made it to the desktop in a
big way.

In principle all of this is good idea. The issue I have with it (in 
principle) is that they are high level solutions to things that do not 
yet have low level solutions.

What I mean is that you craft some functionality and then you limit its 
use case, e.g.

Say you write some script (as I have done) to forcibly close all open 
handles to a filesystem. Your script can operate on any kind of device; 
on plain volumes as well as device-mapped ones. However now you restrict 
the functionality to only work on device-mapped volumes. And then you 
further restrict it to only work on LVM, as that is your use case.

Now you find a need to force-close an encrypted volume with a plain 
filesystem in it, and you can't do it (anymore).

Because the functionality is there but it does not comply with the 
target: it is no logical volume.

Oops. Now suddenly you are screwed and you have to dig in your script to 
find the required calls to other programs to enable the functionality 
runtime for your specific use case now in this moment.

This is what I mean by having high level functionality as a solution to 
a problem that should have been solved at a lower level prior to this. 
Now we have snaps (or clicks) and they do something everyone wants but 
not everyone wants snaps (or clicks). They contain functionality 
everyone wants as a lower level thing but because the thing has been 
entirely tailored for Ubuntu or even tablets perhaps, other people can't 
use it.

For example

You see it already but.

The deduplication is a good strategy for the use case described. But it 
also involves system-wide installation as per the strategy and the 
solution wanted. But /in principle/ the same functionality could also 
simply be realized for a very simple system where some random user just 
puts a package file in his home directory and she then mounts it like 
you have and can access the program without any system-wide things 
(loopback mounting must be supported for a user without priviledges).

It would be the smallest possible solution to the problem. Once you have 
that as a building block (as I had with my script, but chose to throw it 
away), you can construct your high level solution easily on top of that.

But since we present or provide a complete solution to our users and 
nothing other than that, it is take it or leave it.

And so some take it and some leave it but there is no middle ground for 
them.

Add to that the fact that your mount output (/bin/mount, no parameters) 
is now getting polluted with EVERY app you have installed.

It is already impossible to use because of all the cgroups and other 
crap, but now it is getting worse even ;-).

Actually (it is much better than the cgroup crap because this at least 
has some meaning to the user).

Regards.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-06 Thread Ralf Mardorf

Just a very laste note.

On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:
> >> In Windows
> 
> Yes you conveniently break off my statement but (I had to look for it) 
> it was about something that has *nothing* to do with security as it 
> dealth with network shares.

Yes, you mentioned Windows allows to do this and that, but Linux
doesn't, so I pointed out, that Windows is insecure and Linux isn't. I
assume causality. There are reasons that Linux does work different to
Windows.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-06 Thread Ralf Mardorf

I reread all mails and read the new mails. I'm not interested in
continuing the discussion.

> > On 05 Oct 2016, at 16:23, Xen  wrote:
> > Oliver Grawert schreef op 05-10-2016 14:41:
> >> 
> >> there is ... see ~/.xsession-errors and ~/.cache/upstart/
> >> (and there will be a systemd one as well, once switched to systemd user
> >> sessions)
> > 
> > The first file is loaded with random errors but I see some services being 
> > started.

Btw. Oli perhaps doesn't mean the content of the files.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 17:05:

On 05 Oct 2016, at 16:30, Xen  wrote:
Ralf Mardorf schreef op 05-10-2016 15:31:
let alone that some people don't use fstab at all on systemd 
installs.


So what do they use instead?


systemd


I still use systemd with fstab.


Are you intentionally saying half-complete answers here?

You mean that they use mount unit files? Mount services, then.

[Unit]
Description=something
Before=local-fs.target
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/mount crap crop
ExecStop=/bin/umount crop

[Install]
WantedBy=local-fs.target

That's what you mean?

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 17:02:

o


a


On 05 Oct 2016, at 16:23, Xen  wrote:



Errors? Hopefully warnings, such as the GTK GUI crap. When launching a
GUI by CLI I sometimes add 2>/dev/null ;).


KScreen. Lots of it.




Of course there are probably "session" services but I have no clue how 
it works and 99% of users that have spent less than 5 years on Linux 
probably don't know how to do it either.


This is related to the advantage and the disadvantage of Linux user
space. The best approach for those who are clueless and don't want to
learn, is a fruit based OS. However, Ubuntu already is the best Linux
distro for this target group.


Like a Raspberry :).

You basically keep saying that there is no need to improve things, but 
you are taking this from a reactionary approach, not a creative one.


You are that person that says "Oh please, not again" or "Does that party 
need to take place in my house???".



In Windows


Yes you conveniently break off my statement but (I had to look for it) 
it was about something that has *nothing* to do with security as it 
dealth with network shares.



...nothing is secure at all. Users are free to chose Windows. Linux is
for another kind of computer user.


Yes, the one that needs no user-friendliness.

Completely not to the point here. You can enable that same functionality 
in Linux and none would be the worse for it.



A user could chose what ever OS
fits best to the individual needs and moneybag. Apropos standards, if
Ubuntu would follow Richard Stallman's ideas, it would be les to your
needs, IOW there is no standard able to please everybody.


You would first need to argue why *anyone* would need to follow 
Stallman's ideas, and then, why I would need or want to.


I think it is quite irrelevant. You might just as well cite someone that 
wants to blow up the whole world (such as me) and then claim that the 
field of opinions is too diverse to make sense of it.


Disregard that which is irrevant. Pick only ideas that further the goals 
of a usable system. Everything else is beside the point.


(In other words you are only throwing up excuses).

So refuted, here.

So it is not really about system disks for the most part, there is no 
real great issue with having a user having to use sudo or gksudo or 
the like. Because to this day system maintenance really has to be done 
from the shell anyway.


For good reasons not all users get root privileges ;). Keep in mind
that Linux not necessarily is a single user desktop environment.


I just said root privileges were not required for the majority of use 
cases.


That you just said were unwarranted on a Linux system.

But they can be achieved easily anyway if people want to. The system 
stands not in the way of the solution (only you do, in that sense ;-)).


It is only unwilling people that create unrealized solutions.



However on Windows every user... you know.


Why don' t you use Windows instead of Linux? Both operating systems
follow a different approach.


Because both operating systems follow a different approach.


Graphical systems change and are often independable, so we need 
systems that will always be there and remain unsullied by anything 
being done in Gnome or KDE or Unity. It is no good if GUIs create 
their own systems: they should just interface with systems that 
already exist and that you can also access through the command line or 
console.


I'm not using a DE, that doesn't mean that changes of Qt or GTK wot
cause issues for me, but At least I don't suffer from DE related
issues. Windows and Apple don't give you a choice at all.


Yes and my neighbour doesn't use a computer so doesn't suffer any of 
that at all. Great solution to every problem: just don't use it.




I skipped all that systemd related stuff, since it's a little bit to
late to complain about systemd.


When people were planning the war, disconcert was avoided by saying that 
people needed to be focused and not take away from efforts to solve the 
problem.


When the war had started, disconcert was condemned by saying that people 
needed to be patriotic and support the troops.



You want standards and if there is
one, you dislike it.


I never said I wanted standards. I would almost every day prefer a 
system lacking certain functionality rather than a system with 
functionality I have to work my ass off to avoid. But this is a relative 
notion, obviously you cannot choose everything.


I am not happy at all with advances I need to spend time and effort on 
on how to learn to revert.


Every step I make, someone else takes me a step back. Or a step and a 
half. Then I have to spend time learning that system before I can 
advance again.



We already had the systemd discussions before it
was introduced. Note, I'm not a systemd fan, but now we have to become
used to it. I also din't read the snap related part. We don't need to
use snaps, neither on Ubuntu, let alone other distros.


You still

Re: Future and impact of ongoing projects in Linux world

2016-10-05 Thread Colin Watson

On Wed, Oct 05, 2016 at 04:23:38PM +0200, Xen wrote:
> Oliver Grawert schreef op 05-10-2016 14:41:
> >along with that click packages are user packages and being used in
> >ubuntu products on sale since 2015 (snaps will replace them
> >eventually).
> 
> That just means a user can install them, not that they are installed
> specifically for a user?

Not so; click packages may be installed (technically, "registered")
specifically for one or more users.  The process is mediated by a system
facility, certainly, but it can be per-user.  (It's also possible to
register them for use by all users, which is roughly equivalent to a
system-wide installation.)

The reason for it to be mediated by a system facility was so that ten
users all installing the same click package don't end up using ten times
the storage.  Not very interesting on a single-user phone, but
potentially interesting on e.g. a multi-user tablet and would have been
pretty important if click packages had ever made it to the desktop in a
big way.

-- 
Colin Watson   [cjwat...@ubuntu.com]

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world



> On 05 Oct 2016, at 16:30, Xen  wrote:
> Ralf Mardorf schreef op 05-10-2016 15:31:
>> let alone that some people don't use fstab at all on systemd installs.
> 
> So what do they use instead?

systemd


I still use systemd with fstab.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

o

> On 05 Oct 2016, at 16:23, Xen  wrote:
> 
> Oliver Grawert schreef op 05-10-2016 14:41:
>> 
>> there is ... see ~/.xsession-errors and ~/.cache/upstart/
>> (and there will be a systemd one as well, once switched to systemd user
>> sessions)
> 
> The first file is loaded with random errors but I see some services being 
> started.

Errors? Hopefully warnings, such as the GTK GUI crap. When launching a GUI by 
CLI I sometimes add 2>/dev/null ;).

> Of course there are probably "session" services but I have no clue how it 
> works and 99% of users that have spent less than 5 years on Linux probably 
> don't know how to do it either.

This is related to the advantage and the disadvantage of Linux user space. The 
best approach for those who are clueless and don't want to learn, is a fruit 
based OS. However, Ubuntu already is the best Linux distro for this target 
group.

> In Windows

...nothing is secure at all. Users are free to chose Windows. Linux is for 
another kind of computer user. A user could chose what ever OS fits best to the 
individual needs and moneybag. Apropos standards, if Ubuntu would follow 
Richard Stallman's ideas, it would be les to your needs, IOW there is no 
standard able to please everybody.

> So it is not really about system disks for the most part, there is no real 
> great issue with having a user having to use sudo or gksudo or the like. 
> Because to this day system maintenance really has to be done from the shell 
> anyway.

For good reasons not all users get root privileges ;). Keep in mind that Linux 
not necessarily is a single user desktop environment.

> However on Windows every user... you know.

Why don' t you use Windows instead of Linux? Both operating systems follow a 
different approach.

> Graphical systems change and are often independable, so we need systems that 
> will always be there and remain unsullied by anything being done in Gnome or 
> KDE or Unity. It is no good if GUIs create their own systems: they should 
> just interface with systems that already exist and that you can also access 
> through the command line or console.

I'm not using a DE, that doesn't mean that changes of Qt or GTK wot cause 
issues for me, but At least I don't suffer from DE related issues. Windows and 
Apple don't give you a choice at all.

I skipped all that systemd related stuff, since it's a little bit to late to 
complain about systemd. You want standards and if there is one, you dislike it. 
We already had the systemd discussions before it was introduced. Note, I'm not 
a systemd fan, but now we have to become used to it. I also din't read the snap 
related part. We don't need to use snaps, neither on Ubuntu, let alone other 
distros.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 15:56:

On 05 Oct 2016, at 14:59, Himanshu Shekhar wrote:
Standardized things, at least for a distro.


Each distro has got it's policy, a distro specific standard. We could
chose the distro that fits best to our needs.


I didn't want to respond to this idea, but.

People have more choice than just choose which of the bad guys they 
want.


It's a deficiency if you claim nothing could ever be changed or that you 
can't work with a distro to change some things or that you can't invite 
people to like what you are doing -- you can have a developer mindset 
all you want, and there is no reason to say that you can only remain an 
island and that you have to make your changes only for yourself.


This fatalistic and nihilistic approach to change is just utterly 
self-defeating and ugly to me.



The FLOSS approach is to share things and to find common
standards, so it could take longer to find something all people
involved agree.


My country is lauded for this. They call it the Poldermodel.

But if nothing else the Netherlands is quite an ineffective country. The 
politicians are completely impotent.


"The term polder model and especially the verb polderen (to polder) has 
been used pejoratively by some politicians to describe the slow 
decision-making process where all parties have to be heard. The model 
flourished under the "Purple" governments of Dutch prime minister Wim 
Kok, a coalition including the traditional rivals the Labour Party (a 
social-democratic party, whose colour is red) and the People's Party for 
Freedom and Democracy (right-wing liberals, whose colour is blue). In 
the declining economic climate of the early 21st century the model came 
under fierce attack particularly from right-wing politicians and Pim 
Fortuyn in his book entitled De puinhopen van acht jaar Paars ("The 
wreckage of eight years Purple")."


Internally the thing has some sway. But externally the country is 
completely shackled. It has no power to effect anything really, and not 
because of its small size.


That's all I wanted to say here.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 15:44:

On 05 Oct 2016, at 14:49, Xen  wrote:
Ion Windows it is very easy to put some application on some usb stick 
and run it from there, but this is hardly possible even in Linux.


You don't need to link against shared libraries. Neither a container,
nor snap is required to do this.


Sure. I will concur. It's just last time I tried I couldn't get it to 
work. Maybe that's my deficiency but at that time I did not find a way 
to get that particular package statically compiled, it only spewed out 
error after error that I could not fix with my limited C skills.


Regardless that is not really a great way to make an app portable, it 
should suffice to keep your libraries in your own small little directory 
structure.



These apps usually cannot be made portable because they have fixed 
links to libraries.


My /opt directories disagree with your claim. Sure, by default
upstream for good reasons usually links against shared libs.


The nature of solutions is that they first have to be available. It is 
not good enough if they theoretically exist.


It is not even good enough if they practically exist. They first have to 
be accessible and available.


I do not know what packages or applications you are mentioning under 
/opt. Did you compile them yourself?


That is hardly accessible to a regular user, isn't it.

Chrome is portable though at least with regard to its own files. Not 
with regard to the system. That's something packaged by Google.


I mean I think the efforts made by Ubuntu to find a solution to this 
problem is very good. We were just mentioning the difficulties of such 
an approach.


You cannot on the one hand say: Ubuntu has seen a good need for this and 
its snaps system is a solution.
And then on the other hand say to me: Wah, you're complaining about 
nothing.


You are speaking with a split tongue here.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Oliver Grawert schreef op 05-10-2016 14:44:


i must say that in many aspects i find nmcli more powerfull than
ifconfig for scripting ... 

it changed a lot within the last years ... 

one big disadvantage is still that it requires a lot of dependencies ip
or ifconfig do not require ... but disk space is cheap in most cases


To me nmcli is unusable and impossible to remember (how to use it).

Scripting sure but you may not need to remember much if you use it a lot 
and then the script works and you don't need to remember so much.


I don't use ifconfig for scripting much, there are "ip" commands for 
that now?


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

Oliver Grawert schreef op 05-10-2016 14:41:

hi,
On Mi, 2016-10-05 at 04:05 +0200, Xen wrote:

Xen schreef op 05-10-2016 3:32:

>
> In short, the discrepancy between what a user can do and what root
> can
> do, is too big.

The result of this is that most services are installed completely 
system-wide and there is nothing less than that.

how would you deal with ... say 20 users all installing a mongodb
server on your multi user system that all want to use the same
privileged network port ?

The point is not that it would be the best solution in all instances but 
that it is not possible in any instance.

To do it differently (install something by a user).

Besides, what you say is incomprehensible: a user-installed package 
cannot use a priviledged network port, that is the whole point.

Now you may think containers are a solution to that but if you use
e.g. 
LXC for that you still have the same programs running equally 
system-wide but now they are just doing that inside of a container.

That doesn't change the programs, you know.

no, but it makes the above possible (by applying a container based sub-
network like ubuntu-fan does for example)... though note that snaps
have nothing to do with containers (quite the opposite actually).

Still doesn't answer whether they can be user-specific.

In terms of logging: why is there not a daemon that can run for a
user 
specifically?

there is ... see ~/.xsession-errors and ~/.cache/upstart/
(and there will be a systemd one as well, once switched to systemd user
sessions)

The first file is loaded with random errors but I see some services 
being started.

Of course there are probably "session" services but I have no clue how 
it works and 99% of users that have spent less than 5 years on Linux 
probably don't know how to do it either.

Why is there not a user fstab in which the user can specify mounts he
or 
she wants to use? It is possible for libpam-mount but not for
regular 
fstab.

simply because nobody had the balls yet to switch a system completely
to systemd.mount units i guess, but also because it is a security
nightmare to allow people to randomly mount/umount system disks (though
there is fstab-free mounting of USB disks today with udisks2 on every
standard ubuntu system (or flavour))... 

That's true but we have the "disk" group since long and the typical user 
just wants to mount network shares and USB sticks, as you mention.

In Windows any user (not even just an administrator) can take a network 
share and mount it on a drive letter. Just like that. Takes 5 seconds.

In Linux thus far it has been impossible.

Any accessible network share should be allowed to be mounted on any 
accessible user folder just like that (anything to which the user 
already has permissions).

The situation for USB sticks is pretty decent these days although the 
paths are horrible and for other types (e.g. camera) it doesn't quite 
work so well. My camera started working recently (in Kubuntu) before I 
needed gphotofs to mount it which had its own issues (won't dismount 
automatically if the camera is removed, which is also still true of usb 
sticks, you can have a lot of issues if you just pull a stick out). 
Reinserting the stick may not update the view that the user has.

So it is not really about system disks for the most part, there is no 
real great issue with having a user having to use sudo or gksudo or the 
like. Because to this day system maintenance really has to be done from 
the shell anyway.

I have spent like, years, first trying to get autofs to work and it 
often fails (just doesn't work all of the time) and now I have 
libpam-mount setup so that I can mount shares for every applicable user 
and also shares that become different for each user while having the 
same name (home directory on server).

However on Windows every user... you know.

Why are there so few user-oriented systems that a user can use in a 
convenient smaller environment?

- there is no user init system, unless you run stuff through e.g. 
.bashrc or some xinit script or whatever. That is extremely arcane
and 
impossible for a regular user to do.

this is possible since ages, see 
http://upstart.ubuntu.com/cookbook/#session-job

Well upstart was better than SystemD I just had no experience with it. 
And I've been around for a while you know. I have also never seen anyone 
else mention it, ever, anywhere.

also see https://cfp.systemd.io/en/systemdconf_2016/public/events/8
it is actively being worked on for sysstemd sessions ...

I haven't thought much about user-centric vs session-centric but one of 
my main requirements has always been that the system must also work for 
console, ie. it must work even without a graphical system.

Graphical systems change and are often independable, so we need systems 
that will always be there and remain unsullied by anything being done in 
Gnome or KDE or Unity. It is no good if GUIs create their own systems: 
they

Re: Future and impact of ongoing projects in Linux world

> On 05 Oct 2016, at 14:59, Himanshu Shekhar wrote:
> Standardized things, at least for a distro.

Each distro has got it's policy, a distro specific standard. We could chose the 
distro that fits best to our needs.

There are many other standards, some are unix alike, some are Linux specific 
and others are general standards. For example, Linux MUAs tend to fulfill RFC, 
Window has tendencies to ignore RFC.

Another topic are innovations regarding inventions for a specific domain, such 
as plugins for DAWs. Companies programing proprietary software have a boss who 
could introduce a standard for software from this company. The FLOSS approach 
is to share things and to find common standards, so it could take longer to 
find something all people involved agree.

Regards,
Rlaf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

> On 05 Oct 2016, at 14:49, Xen  wrote:
> Ion Windows it is very easy to put some application on some usb stick and run 
> it from there, but this is hardly possible even in Linux.

You don't need to link against shared libraries. Neither a container, nor snap 
is required to do this.

> These apps usually cannot be made portable because they have fixed links to 
> libraries.

My /opt directories disagree with your claim. Sure, by default upstream for 
good reasons usually links against shared libs.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world



> On 05 Oct 2016, at 14:44, Oliver Grawert  wrote:
> disk space is cheap in most cases


Full ACK.
This is very important.
I dislike bloatware, but at least disk space is no issue nowadays.

Regards,
Ralf

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world



> On 05 Oct 2016, at 14:41, Oliver Grawert  wrote:
>> On Mi, 2016-10-05 at 04:05 +0200, Xen wrote:
>> In terms of logging: why is there not a daemon that can run for a
>> user 
>> specifically?
> 
> there is ... see ~/.xsession-errors and ~/.cache/upstart/
> (and there will be a systemd one as well, once switched to systemd user
> sessions)

Not to mention that there at least is one daemon that should run with user 
privileges only:
http://manpages.ubuntu.com/manpages/xenial/man1/jackd.1.html

>> Why is there not a user fstab in which the user can specify mounts he
>> or 
>> she wants to use? It is possible for libpam-mount but not for
>> regular 
>> fstab.
> 
> simply because nobody had the balls yet to switch a system completely
> to systemd.mount units i guess, but also because it is a security
> nightmare to allow people to randomly mount/umount system disks

That's why I mentioned privileges. It's possible to mount all available devices 
by fstab, but only to grant privileges per user, let alone that some people 
don't use fstab at all on systemd installs.

Regards,
Ralf
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-05 Thread Himanshu Shekhar

Moreover, I think that Linux has come a long way and gained much maturity
on the server and enterprise side, thanks to parallel efforts of
"Canonical" and "RedHat" (and "Google").
The sector which Linux has long way to go is Desktop / Laptop and daily
computing. Why do you think people prefer to use Windows or MacOS? That's
what needs to be improved in Linux. Standardized things, at least for a
distro. Lots of customization available, but it should work out of the box.
My dad would not like to go in depth about synaptic and libinput stuff, or
the free/proprietary stuff. Things need to work like a charm, at least to
the maximum extent we can provide.

On Wed, Oct 5, 2016 at 6:23 PM Himanshu Shekhar <
himanshushekhar...@gmail.com> wrote:

> I appreciate Xen's first response stating how things go on in Windows and
> Apple.
> I know that snaps and containers are very different things and function
> differently.
>
> I was less concerned about snaps coming to Ubuntu, than two standards,
> namely Snaps and Flatpak coming to Linux.
> Both are good in their intentions but they would again lead to confusion,
> they way we have today.
> Snaps/Flatpaks are intended to make applications distro-independent and
> unify Linux development. However, two things for the same task would again
> cause confusion about which to use / what will become the de-facto
> standard.
> **REPEAT** This reminds me of the state of Upstart, which after much
> development was replaced by systemd **REPEAT**
>
> I repeat that my concerns are Snaps/Flatpak and Wayland/Mir, not which of
> them is better. (I didn't start this thread to debate which is better).
> It is true that XServer is old and desktop/GUI computing has come a long
> way than the client-server model.
>
> I was eager to know how they are different, and how things in future are
> planned to be, as the current state of development branches in Linux make
> me feel like the chaotic scenario between distributions, packaging and
> graphics server would continue for long.
> --
>
> Regards
>
> Himanshu Shekhar
>
-- 

Regards

Himanshu Shekhar
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-05 Thread Himanshu Shekhar

I appreciate Xen's first response stating how things go on in Windows and
Apple.
I know that snaps and containers are very different things and function
differently.

I was less concerned about snaps coming to Ubuntu, than two standards,
namely Snaps and Flatpak coming to Linux.
Both are good in their intentions but they would again lead to confusion,
they way we have today.
Snaps/Flatpaks are intended to make applications distro-independent and
unify Linux development. However, two things for the same task would again
cause confusion about which to use / what will become the de-facto
standard.
**REPEAT** This reminds me of the state of Upstart, which after much
development was replaced by systemd **REPEAT**

I repeat that my concerns are Snaps/Flatpak and Wayland/Mir, not which of
them is better. (I didn't start this thread to debate which is better).
It is true that XServer is old and desktop/GUI computing has come a long
way than the client-server model.

I was eager to know how they are different, and how things in future are
planned to be, as the current state of development branches in Linux make
me feel like the chaotic scenario between distributions, packaging and
graphics server would continue for long.
-- 

Regards

Himanshu Shekhar
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 14:11:

On 05 Oct 2016, at 12:09, Xen  wrote:


[snip] Main problems in Linux have not been solved and now big
solutions are built on top of it, and the consequence is that those
high level solutions must be as shabby as the low level underneath,
but now a 1000 fold worse, because you cannot get around it anymore.







[snip]  gvfs-udisks2-volume-monitor.service  [snip]


Hi,

what are your main problems?


That is not relevant here but it has nothing to do with gvfs for me.

I was talking about the same things I have already mentioned: on Windows 
it is very easy to put some application on some usb stick and run it 
from there, but this is hardly possible even in Linux. These are basic 
problems created by bad design of systems that already have solutions 
but they are not getting implemented and users suffer site-wide as a 
consequence...


At least, well, it is the same topic as snaps right?

These apps usually cannot be made portable because they have fixed links 
to libraries.


e.g. when I compile Calligra I have to specify the path it will run in 
in advance even before compiling (using configure).


If I change the location of the /binary/ (including its libs) (that I 
just compiled) it will no longer run!!


So for that program the locations were already fixed prior to 
compilation even!!!


This is the same problem sphere as snaps.

As what snaps could be a solution to (if done..., you know...).

The complete dependences on the complete FHS has always been a problem.



Can you explain exactly what you think you are responding to and
what my sentiment would have been to you? I just feel you might be
responding to something I have not said.

My apologies if that is the case for not being very clear.


For example:

"Why is there not a user fstab in which the user can specify mounts he
or  she wants to use?"


I mean what you think I intend by saying that, not my verbatim words (I 
remember them).


Because your response seems to want to discuss a great many things that 
might not even be a problem.


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

2016-10-05 Thread Oliver Grawert

hi,
On Mi, 2016-10-05 at 14:21 +0200, Ralf Mardorf wrote:
> PS: Since you mentioned Network Manager, I'm using scripts to either
> connect by PPPoE or DHCP to the Internet. I don't have other needs
> regarding networks. What is wrong with Network Manager, to provide
> user-friendly network access? You are not forced to use Network
> manager, you could use other tools and/or use command line by
> launching scripts during startup, as I do. In some regards Ubuntu is
> less expert-friendly as other distros might be, but we could chose
> the distro that fit best to our needs.
> 
i must say that in many aspects i find nmcli more powerfull than
ifconfig for scripting ... 

it changed a lot within the last years ... 

one big disadvantage is still that it requires a lot of dependencies ip
or ifconfig do not require ... but disk space is cheap in most cases
... 

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

PS: Since you mentioned Network Manager, I'm using scripts to either connect by 
PPPoE or DHCP to the Internet. I don't have other needs regarding networks. 
What is wrong with Network Manager, to provide user-friendly network access? 
You are not forced to use Network manager, you could use other tools and/or use 
command line by launching scripts during startup, as I do. In some regards 
Ubuntu is less expert-friendly as other distros might be, but we could chose 
the distro that fit best to our needs.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world

On 05 Oct 2016, at 12:09, Xen  wrote:
> [snip] Main problems in Linux have not been solved and now big solutions are 
> built on top of it, and the consequence is that those high level solutions 
> must be as shabby as the low level underneath, but now a 1000 fold worse, 
> because you cannot get around it anymore.
> 
> [snip]  gvfs-udisks2-volume-monitor.service  [snip]

Hi,

what are your main problems? One of my main problems is, that some software 
from bloated desktop environments wakes up sleeping green drives, so I simply 
don't use software from developers, who don't care about damaging green drives. 
This means you won' t find gvfs on any of my installs, let alone that I anyway 
just use a window manager without a desktop environment and that even while 
there are tools available to mount devices by mouse click, without waking up 
and damaging green drives, I mount devices by command line.

On 05 Oct 2016, at 12:09, Xen  wrote:
> Ralf Mardorf schreef op 05-10-2016 9:16:
>> On 05 Oct 2016, at 04:05, Xen "questioned" the way things are managed
> 
> Can you explain exactly what you think you are responding to and what my 
> sentiment would have been to you? I just feel you might be responding to 
> something I have not said.
> 
> My apologies if that is the case for not being very clear.

For example:

"Why is there not a user fstab in which the user can specify mounts he or  she 
wants to use?" 
-  
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-October/016968.html

Regards,
Ralf-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


JMZ schreef op 05-10-2016 7:50:

Is there really a huge learning curve for .bashrc and xinit? .bashrc
is mostly a way to make an alias list.

What I fear about snappy and other modularized systems is unnecessary
complexity. I fear that simple commands such as tar -t are going to be
replaced with a multiplicity of commands which may actually be more
confusing in the terminal.  This complexity will take from terminal
users and give to gui users.


I am not clear on why snappy would have anything to do with tar, unless 
you mean that we would use *other* commands to list the contents of 
archives, rather than tar?


I don't really also see why snappy or anything like it would be more GUI 
friendly? It might do more /for you/ in a way you don't want, and hence 
-- much like e.g. NetworkManager -- makes it easy for those who are okay 
with bad defaults.


That's the general problem I have also: more high level solutions but 
they are quite crappy compared to what you would do yourself. And 
because they are there, it is hard to get around them. They have not 
been thought out fully enough and now a complete solution exists that 
just sucks.


This makes it harder for other people who want to do the things 
themselves and want to do it right.


The problem is not the high level nature of it, but that the building 
stones are still incomplete and downright awful.


Main problems in Linux have not been solved and now big solutions are 
built on top of it, and the consequence is that those high level 
solutions must be as shabby as the low level underneath, but now a 1000 
fold worse, because you cannot get around it anymore.



SystemD has already addressed my needs but it is one of those solutions 
that is built on bad underneath, which is why it is so hard to use and 
like.


This is the contents of /usr/lib/systemd/user:

(On my system, currently):

basic.target gvfs-metadata.service   
 sockets.target
bluetooth.target gvfs-mtp-volume-monitor.service 
 sound.target
busnames.target  gvfs-udisks2-volume-monitor.service 
 systemd-bus-proxyd.service
default.target   obex.service
 systemd-bus-proxyd.socket
exit.target  paths.target
 systemd-exit.service
glib-pacrunner.service   printer.target  
 telepathy-gabble.service
gvfs-afc-volume-monitor.service  pulseaudio.service  
 telepathy-salut.service
gvfs-daemon.service  pulseaudio.socket   
 timers.target

gvfs-goa-volume-monitor.service  shutdown.target
gvfs-gphoto2-volume-monitor.service  smartcard.target

All of the user services there are dbus except one, and it is disabled.

aug 27 22:45:12 xenpc systemd[4003]: Reached target Shutdown.
aug 27 22:45:12 xenpc systemd[4003]: Starting Exit the Session...
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Default.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Basic System.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Paths.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Sockets.
aug 27 22:45:12 xenpc systemd[4003]: Stopped target Timers.
aug 27 22:45:12 xenpc systemd[4003]: Received SIGRTMIN+24 from PID 5286 
(kill).


This is the only log I can find (journalctl --user).

So the system is not actually getting used much, if at all.

(The above will get executed also for session close; this is not just 
reboots or system shutdowns).


Basically I should be able to put a service file in there and it will 
run (or one of the equivalent directories).


--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world


Ralf Mardorf schreef op 05-10-2016 9:16:


On 05 Oct 2016, at 04:05, Xen "questioned" the way things are managed
system wide and per user. I recommend to do either a minimalist Ubuntu
install, e.g. use the server image and uncheck all recommended package
groups, then start to install and set up everything on your own, if
you install packages disable everything that gets autostarted, or
install Arch Linux. My everyday Linux is Arch Linux, but to help Linux
novices, I also installed a minimalist Ubuntu, that fit to my needs.
Everything you questioned isn't worth questioning, you could set up a
Linux install, in a way that it will fit your requirements. Sure,
fstab, is fstab, is fstab, even not required by systemd, but fstab is
a cross-platform approach, system wide for good reasons, that doesn't
mean that you couldn't set up individual automatically mounted devices
per user. If this would make sense or if usage of permissions would be
the better approach, is something to take into account. Anyway,
Ubuntu's policy is user-friend
 lyness, so a default Ubuntu install tries to provide, what is
expected by the majority of computer users. Arch Linux is not user-
friendly, at least not for the mentioned target group, it's
user-centric, in the sense of expert-friendly. You cannot change
_quasi_ UNIX/POSIX alike behavior and common things such as the way
fstab works. You cannot blame Linux for the policy of a distro. You
cannot blame a distro for the policy it does chose.  You could ask
Ubuntu to provide some features for inexperienced users or you could
become more familiar with Linux and user space and set up everything
exactly the way you want. JFTR fstab is used by the system, before
it's clear which user or users will start a session. There's an order
for mechanisms that are well-wrought.


Can you explain exactly what you think you are responding to and what my 
sentiment would have been to you? I just feel you might be responding to 
something I have not said.


My apologies if that is the case for not being very clear.

--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Future and impact of ongoing projects in Linux world