Re: Please Improve Debian for Multimedia Production
Andreas Tille wrote:
On Wed, 25 Mar 2009, Grammostola Rosea wrote:
taste they need to be informed what to choose from. It's like a
where you choose from a menu. Currently we are lacking a complete
"menu" in Debian.
An menu entry for multimedia sounds good to me
(Ubuntu has an menu entry for 'multimedia production:
- music production - video production
(or something close to that).
This is good imo because audio apps are a lot small apps which
clutter up in the menu now.
Nothing against this but I used the term menu in a different than this
technical meaning. I hope this became clear in my mail.
That was clear, but it bumped up a old idea I had in my head ;)
Please take that idea serious...
I think this should be possible: you just pick a few, frequently used
apps (when you build an distro you also have to choose some). Just to
gave an idea.
Although I wouldn't choose those tasks,
Sure - I told you I'm uneducated about your work - one reason more for
you to make the tasks better, right?
But we do not choose a distro - we just have a distro which is called
Debian. And we want to handle the packages which are just inside
Debian. The choice inside Debian was done based on the user interest
and time of developers.
Now you misunderstood what I said ;)
Maybe I was not clear, but the discussion was about which apps you
should choose for such a metapackage, and I said, just pick some common
used apps, to give an idea what is possible.
[bit offtopic, there is another thread about this] I really like the
openness for an RT kernel in Debian. I didn't expect it, so I'm really
happy with. I hope some guys will jump in ! I will do my best to tell it
around and ask people to join [/bit offtopic, there is another thread
The problem is an realtime kernel and a proper configuration for
music production. Without that, you better stay away from music
production imo. Ubuntu Studio has also some metapackages for video,
music and artwork, but they also have an realtime kernel and a tool
to handle the configuration.
Well, I think the problem with the RT kernel was understood and it is
a an issue of just *doing* the actual packaging - so why not just