lukefro...@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 -- Ubuntu-Studio-devel mailing list Ubuntu-Studio-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel