nautilus search function/ how about Nemo?

Emmet Hikory persia at ubuntu.com
Thu Dec 20 02:54:28 UTC 2012


lukefromdc at hushmail.com wrote:
> If Linux ever includes keyloggers or digital rights enforcement software, the open-source nature of the project means that would be detected almost instantly. That should be enough to make sure that malicious software never gets into the kernel except as a patch from a distro. You might think about using kernels directly from upstream if distro versions ever become untrusted, though all patches are applied as source and can be examined.

    We've had both for a while: the event stack can be asked to duplicate
events to another stream, so it's relatively trivial to have a lightweight
userspace program capture all keystrokes, mouse movements, etc.  Most folk
who use this use it for debugging purposes (for which it is incredibly
useful).  For DRM enforcement, one would use the feature that only permits
launching signed binaries, and only sign binaries that enforced the set of
restrictions one wanted enforced: I think most users of this feature are
currently providing kiosk environments, but I may be mistaken.

    What is important here is that we, as the deveopers of Ubuntu Studio,
have a choice about which software we provide, and we can select which
features we enable or disable as we do so.  Sometimes one of the upstream
development teams whose work we have been using will have a philosophy
that differs from our own, and in such cases we may need to seek extensions
or alternatives to what they provide.  Sometimes one of the upstream teams
whose work we have previously ignored will develop a tool that we find very
useful for the sorts of workflows we wish to enable, and in such cases we
may choose to add their software to that which we recommend.

    There is nothing inherent in the Ubuntu project that inhibits these
decisions, and we'd have branding issues were we to select another project
within which to produce our distribution (or create a new project), as well
as having reduced opportunities for collaboration with other flavours (for
exampe, it's fairly nice to just be able to ask the Xubuntu team if we have
an uncertainty about anything XFCE, rather than needing to track it down
ourselves).

    So, at those times when we find that upstream changes affect us, let's
focus on what needs doing to address this (patches, selection of additional
tools, selection of alternate tools, etc.), rather than worrying about
whether we agree with some philosophy expressed by the changes or about
what choices other flavours may be making if those choices don't happen to
correspond with the pursuit of our goals.

    Bringing the subject back to original topic, I was looking at Nemo
about a week ago, and it looks like it won't get into Debian within the
timeframe for this release.  We could certainly include it directly in
Ubuntu (although this may be a bit of work), but if we do so, we'd also
want to update the versions of cinnamon, muffin, etc. we have in the
archives, for which best practice would involve working with the current
Debian mantainers to ensure we can share packaging and revert to inheritance
for raring+1.  Depending on the future direction of Nemo (intending to more
closely integrate with cinnamon), this may or may not be possible as a long
term choice, unless we're planning to also adopt cinnamon: more discussion
with upstream may be useful to determine whether this makes sense, or if
we might do better to direct our efforts towards another file manager or
search provider.

-- 
Emmet HIKORY



More information about the Ubuntu-Studio-devel mailing list