[interal+desktop]Re: [desktop] RFD: Can DeMuDi and Desktop
Debian unite kernel development efforts?
Reply-To:
In-Reply-To: <[🔎] B9DC217F.AFAF%ls.maillist@verizon.net>
X-Operating-System: Linux gramsci 2.4.17
Hi Luke,
i do agree with Andreas about the fact that any project and sub-project
should contribute to the all Debian community, at the same time i dont
see why (sub)projects with common goals should not join forces as Luke
suggested, with no intention of make an isolated project, on the
contrary to benefit the all Debian community.
I really would like to join forces, with the desktop project since, as
they might have interest in our kernel development we are also
interested to provide an easy to use desktop (see my *extra large* email
on the subject) without compromising computer efficiency, for instance
without introducing too much latency, as we noticed on our test about a
year ago.
the Desktop package could have various level of recommendation: 1)
works with any Debian kernel, 2) better if user apply low latency
patches, 3) best with DeMuDi kernel+low-latency+preempt images.
[ It goes without saying the nobody denies anybody to use the DeMuDi
kernel with Debian-junior/med/edu or whatever without installing DeMuDi,
such kernel is perfectly compatible with Debian, and we do not package
any kernel image if it is not on Debian first. The fact that comes with
*DeMuDi* in the package name it is just to differentiate from the Debian
packaged kernel but it is a multi-purpose kernel].
We were about to have a final discussion about the DeMuDi default
Desktop issue on these days (while at the same time we provide via
Debian all the available and packaged desktop). Somehow lately we ended
up testing and enjoying xfce (which is not a Desktop Manager, rather a
window manager but it works with gnome) for the reason i just mentioned
(light easy for novices now resources drinker, no major latency losses),
but it is not a must indeed. We are very open.
As Andreas said a sub project goal should be to create an environment
for the topic of the project with the existing Debian packages. This is
true and it is at the same time what makes DeMuDi integration a bit
harder/slower because sometime the existing Debian package is not enough
for what we are doing. Let me give a couple of examples. We need to
package and make a module package for latest cvs ALSA, since some pro
cards (USB and PCMCIA for instance) are available only in cvs. First i
contact the Debian maintainer, if (s)he does not respond or (s)he is not
interested, as it happened in this mentioned case --I'm not blaming the
maintainer, far from me this idea, again this is part of the way Debian
works and should keep working this way-- we must package ourself ALSA
for DeMuDi. Plus all DeMuDi core applications needed to be tuned a bit
because we use Jack as sound server, and you can't ask maintainer to
necessarily follow us, even if it will come back to Debian somehow
because these changes required a strict cooperation with upstream
authors and changes will be soon become part of the applications and by
consequence all Debian community will benefit. In the mean time we can't
wait for this circle to be completed naturally because DeMuDi has also
deadlines, since we have, luckily received a EC grant. Just to say that
DeMuDi is in a strange position as sub project.
Sorry i dont know why every time i write it ends up to be such a long
message, maybe is because I'm always in a hurry and very little time for
email...
ciao,
marco
--
************************************************************************
* marco trevisani * * http://trevisani.mine.nu marco@centrotemporeale.it
* * http://www.agnula.org -- A GNU/Linux Audio Distribution * * Neither
MS-Word nor MS-PowerPoint attachments please: * * See
http://www.fsf.org/philosophy/no-word-attachments.html * * Gpg
Fingerprint = 6096 84B8 046C A5C9 B538 255E 9FFF 1121 3AFB FFA6 *
************************************************************************
Reply to: