RE: Re: Another idea for comments (Len Ovens)/Pulseaudio removal
I always remove Pulseaudio because I have never been able to get full performance in Kdenlive with it running (choppy with AVCHD based files). I have Jack if I need a mixer, and my small machines (both netbooks and all my Pentium III /low resource experiments) have video playback issues with pulseaudio using so much CPU. I've played with Pulse, never been able to get it to cooperate with these demands. About unremovable packages remember that there is no way to make any package unremovable to anyone with root/sudo access. The binary can have its permissions changed to disallow running or simply be deleted, then the package pinned to prevent reinstallation. In fact, I used to turn Pulseaudio on and off that way (to stop it from respawning if killed) until I found a volume control that worked. That was volti, thanks to another contributor on this list. Of course, someone who understands video editing but not the Linux file system would be stopped by this if APT won't let you pull the package without ripping out a lot of other stuff. Making too many other packages depend on Pulseaudio is a bad idea. Things focussed on pulseaudio obviously would, but such dependancy on, say, an audio editor, would have the effect of making that package incompatable with Kdenlive if AVCHD files are to be used, and with all video players, even Flash, on low resource boxes. Not such a big deal with a meta-you can install the meta, then remove it and anything it brought in you want to remove. Still, that adds complexity that can stop end users dead in their tracks and for that reason alone should be avoided. Dedicated machines are just one reason for this, the fact that everyone's workflow is different is another. Date: Mon, 30 Jul 2012 07:18:49 -0700 From: Len Ovens l...@ovenwerks.net To: Ralf Mardorf ralf.mard...@alice-dsl.net Cc: Ubuntu Studio Development Technical Discussion ubuntu-studio-devel@lists.ubuntu.com Subject: Re: Another idea for comments Message-ID: 905ccfe84c81ace2535e987d108d4b27.squir...@ssl.ovenwerks.net Content-Type: text/plain;charset=iso-8859-1 On Sun, July 29, 2012 10:37 pm, Ralf Mardorf wrote: On Sun, 2012-07-29 at 22:18 -0700, Len Ovens wrote: A fair number of people remove pulse rather than learn how to use pulse and jack together well. I wouldn't use a distro that won't allow me to get rid of Poettering's crap. If a distro would force me to use pulseaudio or systemd at the current state of development, I wouldn't use this distro. Choice is king. Making a package non-removable is not something I want to start doing. For a one use box many things can be removed. In a professional or serious amateur setting, I would expect a one use box. A second multi-use box for desktop use is always an option and someone serious enough to have a one use box, likely has an extra older box around they can use for that. In a professional setting, accounting (with an sql server running) would not be done on a recording box, but on another box anyway. As there is a move to combine the live dvd and alt style install on one ISO (somehow without doubling the size) I am hopeful we will be able to allow just installing one workflow. From your comments and those of others, I am thinking that there is one more workflow meta we need to offer. I am not sure what to name it, I had thought desktop-tools, but that may confused with desktop we already use. Whatever the name it would include the packages we ship now as standard to combine normal desktop use with studio use. Things like pulse, auto-update, CUPS, firefox (not sure about this one, some applications use a browser for docs... dillo instead?), any of the media playback options that require gstreamer (and pulse). That is a list off the top of my head, so neither complete or correct. Another project in the works is a mode switch that turns off services harmful to audio (or whatever) use such as cron and friends, pulse (or at least bridging) and set cpu-freq to performance (or perhaps a user selected speed... I haven't tried that yet... it is a lot harder as the config utility would require finding out what speeds are supported) Even unload bad-for-audio kernel modules (like the wireless module on one of my machines). I am actually using this on my netbook for audio work now and it works very well. It takes hardware that has no serious audio application and makes it into a quiet solid audio machine. Right now the files are hand configured, the next step is a gui configuration tool with suitable documentation. The way I use it is as a tray icon with a click-select to select the mode. It can also be setup to change modes on jackd startup/shutdown. I have not looked at session managers doing so as yet, but if they can run a command they could. There are a lot of options. I don't think we should limit Studio to only one. -- Len Ovens www.OvenWerks.net
RE: Re: Another idea for comments (Len Ovens)/Pulseaudio removal
On Tue, July 31, 2012 10:49 am, Luke Kuhn wrote: I always remove Pulseaudio because I have never been able to get full performance in Kdenlive with it running (choppy with AVCHD based files). I have Jack if I need a mixer, and my small machines (both netbooks and all my Pentium III /low resource experiments) have video playback issues with pulseaudio using so much CPU. I've played with Pulse, never been able to get it to cooperate with these demands. About unremovable packages remember that there is no way to make any package unremovable to anyone with root/sudo access. The binary can have Whoa, I wasn't suggesting making any package unremovable. It was: Choice is king. Making a package non-removable is not something I want to start doing. To make it any more clear I don't see making something unremovable as a solution to any problem. I don't know how (depends can make harder I guess) and I don't really want to learn. What I do want to do is make it easier to remove a meta without causing problems, but even better make it possible not to install an unwanted meta in the first place and possible to install later if needed. Possible to remove a single package even if it was installed as part of a meta package. I think that covers it... but it may not. its permissions changed to disallow running or simply be deleted, then the package pinned to prevent reinstallation. In fact, I used to turn Pulseaudio on and off that way (to stop it from respawning if killed) I may use that in some way. until I found a volume control that worked. That was volti, thanks to another contributor on this list. Of course, someone who understands video editing but not the Linux file system would be stopped by this if APT won't let you pull the package without ripping out a lot of other stuff. I want to prevent that too. I would like the user to be able to just remove pulse if they want to. I like flexibility. Making too many other packages depend on Pulseaudio is a bad idea. Things focussed on pulseaudio obviously would, but such dependancy on, say, an audio editor, would have the effect of making that package incompatable with Kdenlive if AVCHD files are to be used, and with all video players, even Flash, on low resource boxes. I don't know that we would have to even make gstreamer depend on it because it will work direct to ALSA. In fact I can't think of anything that would have to have pulse except a pulse plugin/module package. Pulse is default because someone new to audio may not expect not to be able to play more than one stream at a time, for example listen to oggs and check out a video at the same time. This is not normal for audio production of coarse. Not such a big deal with a meta-you can install the meta, then remove it and anything it brought in you want to remove. Still, that adds complexity that can stop end users dead in their tracks and for that reason alone should be avoided. Dedicated machines are just one reason for this, the fact that everyone's workflow is different is another. So are you saying Studio should not offer the installing user a choice of which workflows to install? Or that we should not install all workflows and then let the user remove some? I don't think we can offer the first without the user being able to unload a meta. But the fewer a machine starts off with the better IMO. -- Len Ovens www.OvenWerks.net -- 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
RE: Re: Another idea for comments (Len Ovens)/Pulseaudio removal (Len Ovens)
Most certainly I was not trying to say that. I just was comparing that to the worse situation of a locked-down distro that requires hacking to get rid of unwanted programs. I've seen so much stuff come along that I am better off without, such as support for pay software in software center or pulseaudio's resource consumption. Ideally a user would not have to install, nor to download, anything they aren't going to actually use. Removal after the fact is second best, but beats the hell out of having to screw with the filesystem because someone added dependancies to something that it will run without. Even if the installer is a big one with all workflows (bandwidth), having to first install and then remove unused software adds time to the installation, plus opportunities for file system corruption if there are hardware issues or on some kinds of flash media. Leaving unused software on-disk is also a security issue (more possible attack vectors) on any machine that will ever be connected to a network or even used with removable drives. Ideally there would be some way to manage separate installers for each workflow, plus an all installer, to reduce download bandwidth issues. For the alternate disk full of Debian packages that would not be such a problem, might be a mess for live installers, though. So are you saying Studio should not offer the installing user a choice of which workflows to install? Or that we should not install all workflows and then let the user remove some? I don't think we can offer the first without the user being able to unload a meta. But the fewer a machine starts off with the better IMO. -- Len Ovens www.OvenWerks.net -- 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
Re: Another idea for comments
On Sun, July 29, 2012 10:37 pm, Ralf Mardorf wrote: On Sun, 2012-07-29 at 22:18 -0700, Len Ovens wrote: A fair number of people remove pulse rather than learn how to use pulse and jack together well. I wouldn't use a distro that won't allow me to get rid of Poettering's crap. If a distro would force me to use pulseaudio or systemd at the current state of development, I wouldn't use this distro. Choice is king. Making a package non-removable is not something I want to start doing. For a one use box many things can be removed. In a professional or serious amateur setting, I would expect a one use box. A second multi-use box for desktop use is always an option and someone serious enough to have a one use box, likely has an extra older box around they can use for that. In a professional setting, accounting (with an sql server running) would not be done on a recording box, but on another box anyway. As there is a move to combine the live dvd and alt style install on one ISO (somehow without doubling the size) I am hopeful we will be able to allow just installing one workflow. From your comments and those of others, I am thinking that there is one more workflow meta we need to offer. I am not sure what to name it, I had thought desktop-tools, but that may confused with desktop we already use. Whatever the name it would include the packages we ship now as standard to combine normal desktop use with studio use. Things like pulse, auto-update, CUPS, firefox (not sure about this one, some applications use a browser for docs... dillo instead?), any of the media playback options that require gstreamer (and pulse). That is a list off the top of my head, so neither complete or correct. Another project in the works is a mode switch that turns off services harmful to audio (or whatever) use such as cron and friends, pulse (or at least bridging) and set cpu-freq to performance (or perhaps a user selected speed... I haven't tried that yet... it is a lot harder as the config utility would require finding out what speeds are supported) Even unload bad-for-audio kernel modules (like the wireless module on one of my machines). I am actually using this on my netbook for audio work now and it works very well. It takes hardware that has no serious audio application and makes it into a quiet solid audio machine. Right now the files are hand configured, the next step is a gui configuration tool with suitable documentation. The way I use it is as a tray icon with a click-select to select the mode. It can also be setup to change modes on jackd startup/shutdown. I have not looked at session managers doing so as yet, but if they can run a command they could. There are a lot of options. I don't think we should limit Studio to only one. -- Len Ovens www.OvenWerks.net -- 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
Re: Another idea for comments
On Mon, July 30, 2012 8:37 am, Ralf Mardorf wrote: I didn't follow this thread. Is there a list with the available meta-packages and the included files somewhere available. I suspect this thread is about Quantal. FWIW I'll stay at Precise, since it's a LTS. Much used by Linux folks is Chromium, I guess it's not an option for Ubuntu Studio. However, most people from Linux and Windows know Firefox. synaptic with a search for ubuntustudio will give a list of our metas. The main ones are recording, graphics and video. Publishing and photgraphy are committed too, but would not be available for the LTS. These are usable right now for those who wish to add one to another ubuntu flavour. These would be the options that were available while installing the alternate dvd ubuntustudio used to ship. We have (for now) lost this flexability. Chromium is not a non-option. -- Len Ovens www.OvenWerks.net -- 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
Re: Another idea for comments
On Sat, July 28, 2012 8:23 pm, Emmet Hikory wrote:
Another option would be to include all the workflows in the live
environment, again modify the ubiquity frontend, and uninstall all the
workflows *not* selected by the user during the software removal phase.
The main issues with this solution are that either the user might end up
missing software they expected to be there (because they failed to select
some workflow they wanted but didn't know they wanted), and that the
uninstallation phase will take a long time/waste a lot of power/${random
negative interpretation of shipping useless software and removing it}.
Last cycle ubiquity seemed to copy everything from the cd/dvd to the drive
and then remove things not needed (like ubiquity itself). I have noticed
that this cycle, ubiquity has a stage where it calculates which files
not to copy in the first place. I would think this calculation would take
the same amount of time if the files not to be copied was large or small
(I could be wrong) and there would be no files removed at the end.
However, my concern is that installing from a live dvd/cd has some
interesting effects on depends. These effects are not very noticeable for
most flavours of ubuntu because they have one set of software that they
install not 5 or 6. The install depends on everything, that is in our case
where in the past graphics items would have depended on the graphics meta
with the alt install, with the live ubiquity install those apps also
depend on the install itself. This means, if the user chooses to uninstall
one of these metas, the meta itself is uninstalled but not the apps that
should only be dependants of that meta. This has meant that some users
have uninstalled the apps manually not realizing that one or two of the
apps might also be a depend for another package (like a font for desktop
in the case that started me looking at this). These users end up with a
broken system.
Perhaps this should be considered a bug in the ubiquity installer or the
live dvd/cd.
Users seem to have no problem with the idea that we have a live ISO with
all the apps on it so users can see them and that the install would be the
same for that reason, but they do seem to expect they can remove parts of
it.
Separately from the above, as part of my catch-up reading, I thought
there
were some threads about merging the live and alternate images. While I
Yikes! My first thought is that would greatly increase our ISO size (I was
thinking double) but it would allow a better install. We do have one of
the biggest ISOs and doubling it does not leave much room on a DVD... but,
I think the future of things is to install from usb stick anyway. DVD
drives are less often included as part of the hardware already, most new
home video systems also accept USB sticks... I think it is only a matter
of time before home movies are distributed on a read only memory stick (or
maybe even with a limited number of plays). Anyway, it will be interesting
to see where this goes.
Len
--
Len Ovens
www.OvenWerks.net
--
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
Re: Another idea for comments
Len Ovens wrote: However, my concern is that installing from a live dvd/cd has some interesting effects on depends. These effects are not very noticeable for most flavours of ubuntu because they have one set of software that they install not 5 or 6. The install depends on everything, that is in our case where in the past graphics items would have depended on the graphics meta with the alt install, with the live ubiquity install those apps also depend on the install itself. This means, if the user chooses to uninstall one of these metas, the meta itself is uninstalled but not the apps that should only be dependants of that meta. This has meant that some users have uninstalled the apps manually not realizing that one or two of the apps might also be a depend for another package (like a font for desktop in the case that started me looking at this). These users end up with a broken system. My understanding is that packages that are installed are marked as automatically installed unless either 1) the user specifically chose to install the package, 2) the package is a dependency or recommendation of a package in Section:metapacakges, or 3) the package is a metapackage selected at install time. Removing the dependencies/recommendations of a metapackage safely requires using apt-mark to indicate that these are all automatically installed, and using apt-get autoremove to select the subset of automatically installed packages it is safe to remove. Documenting this is *hard* (there are manpages, etc., but they aren't considered very accessible to some hypothetical average user who doesn't want to understand the details of the packaging system). The reason that packages that are dependencies of metapackages default to being marked intentionally installed is that there were persistent complaints in the past that uninstalling package X (which the user never used nor wanted to use) would uninstall metapackage Y (because of a dependency relation), which would then cause half the system to uninstall (because it was the flavour-defining metapackage). If there is sufficient interest, it should be possible to write a tool that allows for clean install/remove of each workflow, where install means find out which packages are missing, and install them and their dependencies and remove means find out which packages are not needed if only this workflow is missing, and remove them (and only the unneeded ones). Separately from the above, as part of my catch-up reading, I thought there were some threads about merging the live and alternate images. While I Yikes! My first thought is that would greatly increase our ISO size (I was thinking double) but it would allow a better install. We do have one of the biggest ISOs and doubling it does not leave much room on a DVD... but, I think the future of things is to install from usb stick anyway. DVD drives are less often included as part of the hardware already, most new home video systems also accept USB sticks... I think it is only a matter of time before home movies are distributed on a read only memory stick (or maybe even with a limited number of plays). Anyway, it will be interesting to see where this goes. I think there was talk about finding ways to *not* double the size, rather providing both interfaces for the install from the same set of source data. Although I don't know the details of the implementation, all the possibilities I can imagine would imply that there would be more means by which greater flexibility could be implemented for the Ubuntu Studio install experience. -- 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
Re: Another idea for comments
On Sun, July 29, 2012 4:34 pm, Emmet Hikory wrote: I think there was talk about finding ways to *not* double the size, rather providing both interfaces for the install from the same set of source data. Although I don't know the details of the implementation, all the possibilities I can imagine would imply that there would be more means by which greater flexibility could be implemented for the Ubuntu Studio install experience. I think it would be very welcome for UbuntuStudio. To be honest, I think the current way things are saves us from ourselves as almost all of the apps in each meta are depends rather than recommends. So if things were set up so the user could remove a meta, removing any one of the apps would remove the whole meta too. So I look forward to it, but also realize it would mean a lot of testing to make sure things worked the way we intended. A personal note. I think with the size of disks any more there is less reason for removing a meta once installed than in the past. Installing less in the first place still has it's place. uninstalling an app that causes trouble with other software is different again. A fair number of people remove pulse rather than learn how to use pulse and jack together well. -- Len Ovens www.OvenWerks.net -- 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
