Default group

Nicolas Michel be.nicolas.michel at
Thu Oct 18 08:13:12 UTC 2012

I think that the wizard should also be "smart enough" to asks questions
related to the content to share. Example, if you want to share a video or
an audio file, maybe it's best to share it via DLNA if the viewer is on the
same LAN. Then it needs to ask a question like :
- do you want to share the video/audio in the purpose of the other user to
play it in a multimedia player? (DLNA)
- do you want to share the video/audio so the other user can copy it on its
computer? (File sharing)

As explains in my previous mail, the option "connect to a share that
someone gave me" would only be a wrapper that understand the URI we gave to
it : DLNA, Samba, Webdav, NFS ...

I also think that if wizards is really what usual users need, as a
technical guys I often find them limitating because of their abstractions,
I need to think what the dev wanted to say (technically speaking). For
example, if I know what is DLNA and that I want to share a media via DLNA,
using traditionnal tool takes some times to make it working, and using the
mentionned wizard will need me to choose the "right answers" to be able to
make a DLNA sharing. So I think that:
1) there should be a first question like :
- I'm a technical guy and I know what I want
- I only want to share something and the how is not of my interest
(then it doesn't opens a new windows but only change the sets of questions
the wizard will ask) : you could also add a check box "remember my choice
for further same action".

2) whatever you choose at start (technical guy) you should have a 2 columns
window. On the biggest one on the left : the Q&A. On the little column on
the right, a technical recap of what technical solution will be used,
related to the questions answered. You should be able to click on links
there to change configuration manually (despite the answers given). Usual
users won't take care of it. Technical guys will understand what the wizard
will really do. That's transparency.

So the concept is that there should be a kind a "model" of a share :
something with some fields to configure:
- what to share : filesystem path to the item to share
- kind of share : dlna, samba, nfs, webdav, ubuntu one ...
- permissions that will be modified: which permissions on which level
(filesystem? sharing service? ...)

The purpose of the Q&A is only to complete that model. So the last step of
the wizard that will configure everything will only have to take care of
that "profile". And so the Q&A can be changed/adapted easily through
versions of the app without having to rewrite the code that really do the

2012/10/18 Nicolas Michel <be.nicolas.michel at>

> I agree that there should be something done on the UI to support ACL on
> Ubuntu (not like eiciel). But I really don't agree when you say that
> Windows is already doing it well!
> Honnestly, nobody never understood these pretty technical concepts of
> permissions (I mean usual end-users, not us that are talking on a dev linux
> distrib mailing-list). I still organize some gaming LAN with friends (on
> Windows of course ...) and most of the time, when someone want to share
> something, they prefer :
> - copy their things to an external DD
> - give the external DD to their friend
> - the friend then copy the content on his local disk
> Although they're all connected to a gigabit switch, using the external
> disk is not the fastest but it's the simpler. I already explained how to
> make a network share but it involved too much computer skills : IP,
> filesystem, permissions, network share... So they continue to use their
> external disk. I don't even try to explain it anymore ;)
> Conclusion: instead of creating an UI that just reflects the low level
> understanding of ACL which won't help the majority of peoples we need
> something better. In a UI, things needs to be astracted. So we should think
> about "sharing" as a Service like in SAAS: you really don't know which
> technical configuration is involved but it works. So I think that a
> "sharing" options should launch a wizard wich ask simple questions that do
> not involve any technical skills (but with some hints for technical guys)
> like :
> 1) to who do you want to share the directory:
> a: another user on this computer
> b: another computer on my local network (LAN) (#maybe that using something
> like webdav would be simpler than Samba or NFS?)
> c: someone which is connected to internet like me (# and then using
> something in the cloud like Ubuntu One?)
> 2) Is the other user can delete and modify the content or only see it?
> The wizard do whatever needed for it to work : modify filesystem
> permissions, configure a Samba Share, or a Webdav service ... At the end of
> the wizard, it tells the instructions to give to the other guy how to
> access the share (give an url and saying to type it in their internet
> browser, a path and saying how to use it...).
> To go further, I think "sharing" should even not be implemented into
> nautilus or other file browser! It should be something standalone with a
> shortcut in the dash, which opens a windows like the system configuration
> one with some icons like :
> - see my current shares
> - create a new share
> - connect to a share that someone gave me
> What do you think?
> Nicolas
> 2012/10/18 John Moser <john.r.moser at>
>> On 10/17/2012 06:43 PM, Marc Deslauriers wrote:
>>> On 12-10-17 05:45 PM, John Moser wrote:
>>>> On 10/17/2012 05:34 PM, Marc Deslauriers wrote:
>>>>> On 12-10-17 03:52 PM, John Moser wrote:
>>>>>> First, he must find the sysadmin.  The sysadmin must then put wriker
>>>>>> in group jkirk.  Also, ~jkirk must be group-readable, as must any
>>>>>> files.
>>>>> In a default Ubuntu installation, jkirk's files are already accessible
>>>>> to other users.
>>>> Yeah I just looked and saw that, my whole $HOME is world-readable.
>>>> This displeases me.  I'd prefer default $HOME chmod 700.
>>> As I said, we wanted people to be able to share files by default without
>>> having to understand granting permissions. This has already been
>>> discussed to death, although it's been a while.
>> It's good to revisit things.  I'm bringing up what's turning into an
>> evolving alternate proposal, at this point I've gotten as far out as
>> suggesting UI changes and a sticky bit (= /tmp) directory acting as a
>> "Shared Documents" between users, which I'm guessing didn't come up last
>> round.  Sometimes the rules change.
>>  Of course, you're absolutely right. I'm not sure what I was thinking
>>> there for a sec. :P
>> Wrong facility probably.  Changing permission != changing group, which is
>> what this discussion started on.
>>> I'm not sure this proposal would be simple enough to be understood by
>>> most non-technical users. Also, last time we looked at using extended
>>> attributes, there were issues with proper support in common tools,
>>> backup software, certain filesystems, etc. This would need to be looked
>>> at again to see if extended attributes can be used now. It's certainly
>>> worth investigating it again.
>> I may as well continue beating the "Look at Windows" horse, it's done
>> this right for ages anyway.  You should consider your user base though:
>>  they've already installed Ubuntu.  Most of them.  Some probably got a
>> tablet or such that came with it, but single-user systems likely do not
>> care.  We're talking about shared multi-user systems where everyone isn't
>> admin, which is kind of a narrow case.
>> That's less "most users don't need to know how" and more "most users
>> won't be faced by a sudden, surprising, confusing change" (like moving from
>> Gnome2 to Ubiquity or Gnome3 by default?).  In other words, I suspect most
>> users aren't particularly attached to the "sharing my files with everyone
>> else" case.
>> Finally on that discussion, the current case is--as discussed--a default
>> "Share with everyone, and the user has to take an unknown technical step to
>> stop that."  That means it's hard (for some value of "hard") for some 14
>> year old girl to stop her little brother from reading her diary.
>> Fortunately actual e-mails are stored in a directory Thunderbird by default
>> forces to 700, although any attachments you save you'll need to purposely
>> revoke permission on.  Mostly to the point, documents, saved attachments,
>> saved files off Web sites, PDF collections of Victorian era pornography
>> downloaded from torrents, all by default available without jumping through
>> technical hoops.
>> Don't know about common tools, backup software.  I'm well aware it's not
>> straight out-of-box supported by Thunar, Nautilus, and Konqueror--it works,
>> but their file properties dialogs don't let you manage those permissions.
>>  Again, Windows does this right.
>> As for filesystems, POSIX ACLs tend to cause issues with read latency for
>> inodes not in disk cache.  XFS with 256 byte inodes takes something like
>> 9uS to read a non-ACL inode, 7000uS for an ACL inode; XFS with 512 byte
>> inodes takes 9us either way; and other file systems tend to behave like XFS
>> with 256 byte inodes (9uS-15uS without POSIX ACL, 1000-1500mS with it).
>>  This is because another seek-and-read must be done.  Not a problem on SSD.
>> not a problem on a warm system, minor performance issue at first boot.
>>  This isn't something that's going to slow the system to a crawl:  these
>> ACLs are only going to be set on user-owned files, and even then the
>> proposed semantics favor setting them on a directory here and there and so
>> you lose a millisecond or three once in a great while.
>> Do note that performance issues are circa 2003:
>>>> The only other thing needed would then be a "Shared Documents" alike
>>>> (borrowing from Windows again--it's a pile of crap but that doesn't mean
>>>> everything associated is terrible by default) supplying a place for
>>>> folks to put shared files or such secured shared folders, made sticky of
>>>> course.
>>> Well, right now we're defaulting to sharing everything except private
>>> information in private directories. Your proposal is basically to share
>>> nothing, and create exceptions. If this is to be discussed again, we
>>> probably need to figure out if our users are able to understand file
>>> permissions well enough to be able to share documents.
>> I recall Windows XP notifying users that it was in fact going to
>> "privatize" directories after upgrade, or some such.  Such flip-flops have
>> been done.
>> Users will probably not understand anything until it's happened to them
>> once or twice.  A Shared Documents folder where such things would go to be
>> shared would wind up by default having files in it that everyone can read,
>> and folders by default being readable and writable by everyone, with files
>> in those folders readable and writable by everyone.  The user would still
>> have to take action to tighten it down--not something that can be helped,
>> but something that we can facilitate.
>>> Of course, this is all moot without home directory encryption, and when
>>> you turn that on, there's basically no sharing at all.
>> /home/shared not encrypted.
>> And we're relying on the graces of nobody jacking the machine with a
>> bootable USB drive, yes.  These are, in the end, just soft barriers.
>>  Marc.
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.**<Ubuntu-devel-discuss at>
>> Modify settings or unsubscribe at:**
>> mailman/listinfo/ubuntu-devel-**discuss<>
> --
> Nicolas MICHEL

Nicolas MICHEL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Ubuntu-devel-discuss mailing list