Re: State of cleanup-audio-jumble
Hi, On Wed, 2007-07-25 at 08:18 +0100, Sitsofe Wheeler wrote: > I thought PulseAudio had gained libflashsupport already - > http://pulseaudio.vdbonline.net/libflashsupport/ ? No. Notice that libflashsupport is not in Ubuntu. Thanks. signature.asc Description: This is a digitally signed message part -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Single CD for Server & Desktop?
I'm curious why there are 2 CDs, one for Server and one for Desktop. Is it not possible to have a check box at installation time that says: * I would like to install an Ubuntu Desktop [ ] * I would like to install an Ubuntu Server [ ] Just idly curious. ;-) -- Chris "To announce that there must be no criticism of the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public," said President Theodore Roosevelt. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Single CD for Server & Desktop?
On Sat, Jul 28, 2007 at 04:33:38PM -0500, Christofer C. Bell wrote: > I'm curious why there are 2 CDs, one for Server and one for Desktop. > Is it not possible to have a check box at installation time that says: > * I would like to install an Ubuntu Desktop [ ] > * I would like to install an Ubuntu Server [ ] If we could, we would. :) There would simply not be space enough on the CD for all the software. -- Soren Hansen Ubuntu Server Team http://www.ubuntu.com/ signature.asc Description: Digital signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Single CD for Server & Desktop?
Yea, server isn't just a subset of desktop, as it installs minimal and a LAMP setup, so it would significantly bump up the size. We're pushing close to 700mb now. Plus most users would have no use in this. It would only be convenient enough for the people who could handle a server and downloading a new ISO... plus a liveCD for a server install would just be silly =D On 7/28/07, Christofer C. Bell <[EMAIL PROTECTED]> wrote: > > I'm curious why there are 2 CDs, one for Server and one for Desktop. > Is it not possible to have a check box at installation time that says: > > * I would like to install an Ubuntu Desktop [ ] > * I would like to install an Ubuntu Server [ ] > > Just idly curious. ;-) > > -- > Chris > > "To announce that there must be no criticism of the president, right > or wrong, is not only unpatriotic and servile, but is morally > treasonable to the American public," said President Theodore > Roosevelt. > > -- > Ubuntu-devel-discuss mailing list > Ubuntu-devel-discuss@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Cheers, Bryan -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Updating software between releases - where backports/SRU isn't enough
I thought I'd bring up an issue that I see with Ubuntu - and most Linux distributions as a whole.Anyway, the issue is that once a release is declared "stable", there are no more updates beyond security updates available - at least without resorting to ugly tarballs or random unofficial package repositories. This is all fine and dandy, unless you need a feature or a bugfix deemed non-critical - especially if it's the kernel or some other low-level component like Xorg. These types of things are covered by neither Stable Release Updates nor Backports, and as such users who need a new kernel for hardware support or who need many other software updates are left going about it the old tarball way or by trying to install software from the unstable repositories. In my own case, the situation is that the 2.6.20 kernel in Feisty can't suspend my MacBook. This is fixed in 2.6.22, but to install this I must either 1) get the Gutsy kernel, in which case I can't install linux-headers (needs glibc 2.6) 2) compile my own kernel from source, or 3) run Gutsy. I can see many other situations where this come up - simply Google the many "running Ubuntu on xyz" articles and you'll find countless "recompile this", "install this from unofficial repository X" etc etc. This may be fine for me and for most experienced users, but it remans an issue that, IMHO, must be resolved if Bug #1 will ever be fixed. Is anyone in Ubuntu is doing any work on this issue? This could possibly include expanding backports, but could also entail making it easier to build from fresh source for the new user (think BSD ports, but easier). If so, or if there is interest in working on this, I'd love to help - it seems like an area where much improvement could be made. I hope this e-mail doesn't rub anyone the wrong way - I'm NOT asking for anything to be done specifically for me. I appreciate all the good work Ubuntu and Debian are doing, and I hope it continues. Tim P.S. I may send this to debian-devel as well, as this issue is also present (albeit to a greater degree with their length between stable releases) in Debian. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
On Saturday 28 July 2007 19:28, Tim Hull wrote: > I thought I'd bring up an issue that I see with Ubuntu - and most Linux > distributions as a whole.Anyway, the issue is that once a release is > declared "stable", there are no more updates beyond security updates > available - at least without resorting to ugly tarballs or random > unofficial package repositories. This is all fine and dandy, unless you > need a feature or a bugfix deemed non-critical - especially if it's the > kernel or some other low-level component like Xorg. > > These types of things are covered by neither Stable Release Updates nor > Backports, and as such users who need a new kernel for hardware support or > who need many other software updates are left going about it the old > tarball way or by trying to install software from the unstable > repositories. In my own case, the situation is that the 2.6.20 kernel in > Feisty can't suspend my MacBook. This is fixed in 2.6.22, but to install > this I must either 1) get the Gutsy kernel, in which case I can't install > linux-headers (needs glibc 2.6) 2) compile my own kernel from source, or 3) > run Gutsy. > > I can see many other situations where this come up - simply Google the many > "running Ubuntu on xyz" articles and you'll find countless "recompile > this", "install this from unofficial repository X" etc etc. This may be > fine for me and for most experienced users, but it remans an issue that, > IMHO, must be resolved if Bug #1 will ever be fixed. > > Is anyone in Ubuntu is doing any work on this issue? This could possibly > include expanding backports, but could also entail making it easier to > build from fresh source for the new user (think BSD ports, but easier). If > so, or if there is interest in working on this, I'd love to help - it seems > like an area where much improvement could be made. > > I hope this e-mail doesn't rub anyone the wrong way - I'm NOT asking for > anything to be done specifically for me. I appreciate all the good work > Ubuntu and Debian are doing, and I hope it continues. > > Tim > > P.S. I may send this to debian-devel as well, as this issue is also present > (albeit to a greater degree with their length between stable releases) in > Debian. For LTS releases I agree this is a problem. I also think Ubuntu is addressing it in a sane way. Most of the changes included in the upcoming 6.06.2 are related to supporting newer hardware. My launchpad-foo isn't up to providing a link, but you can find a link of bugs that are targeted for 6.06.2. For non-LTS releases, I'm not convinced there's a sane way to approach this. I'd be curious if you have a specific proposal. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
> > > For LTS releases I agree this is a problem. I also think Ubuntu is > addressing > it in a sane way. Most of the changes included in the upcoming 6.06.2 are > related to supporting newer hardware. My launchpad-foo isn't up to > providing > a link, but you can find a link of bugs that are targeted for 6.06.2. > > For non-LTS releases, I'm not convinced there's a sane way to approach > this. > I'd be curious if you have a specific proposal. > I'd say it is definitely an issue with both LTS and non-LTS releases - though it is definitely much more of an issue with LTS releases (and Debian, which has a release cycle approximately the same length as LTS). I had a couple ideas here with respect to both cases, though... My idea would be to basically split the existing backports into two categories: 1) An "Optional Updates" category, which contains supported release updates that are not installed by default. This would include high-demand userspace application updates like Firefox 3.0 (if it came between releases). It would include some system-space updates, but only for bugfix purposes or hardware support (a new kernel, for instance, or an Xorg video driver). For instance, issues such as my MacBook's lack of suspend would be resolved here. 2) For all other backports, add an easy way to self-build packages from source in addition to the existing unsupported backports section. This could be from the unstable release source, or from the proposed "Grumpy Groundhog" section. Basically, one would add the appropriate source repositories into Synaptic, and the latest binary and source releases would be displayed with an option to "build from source" - which would fetch all dependencies etc. We could even add the option to set compiler flags for advanced users (might get some Gentoo users to switch :)). I do know apt provides some of this infrastructure (apt-build etc), but it could be tested and integrated. I know this may be a completely unfeasible idea, but it is what I was thinking of within the current release cycle. IAJALU (I Am Just A Lowly User), though... Tim P.S. Honestly, my preference would be for a slightly different release cycle. Each LTS release would be based off Debian stable (and would come slightly after said Debian stable), and each succeeding release would be based off the LTS with backported updates (i.e. we'd pull new versions of Firefox, the kernel, etc in, but we wouldn't update glibc just for the sake of updating glibc. Updates to be incorporated in the next release would be backported on a rolling basis in the "Optional Updates" category. This would seem to result in more stable releases while making Ubuntu more compatible with Debian. IANAUD, though... -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
On 29/07/07 07:28, Tim Hull wrote: > I thought I'd bring up an issue that I see with Ubuntu - and most > Linux distributions as a whole. > Anyway, the issue is that once a release is declared "stable", there > are no more updates beyond security updates available - at least > without resorting to ugly tarballs or random unofficial package > repositories. This is all fine and dandy, unless you need a feature > or a bugfix deemed non-critical - especially if it's the kernel or > some other low-level component like Xorg. This reply is longer than I intended and you may feel that I'm telling you off. That is not the case. While I understand what you're asking for, perhaps I'm able to convince you that it makes no sense. I write software for a living and I support clients with different configurations all around the country. Some clients have access to broadband, many others have access to a tin-can and wire - that is 28.8k dialup or worse. These clients are running Dapper LTS for the simple reason that it works and continues to work. They just need their computer to work. While I care about security fixes, they don't. While I care about the latest version of something like Firefox, they don't. All this by way of background. The whole point of an LTS system is that it is in a known state and continues to stay in a known state. It might not be perfect, but it continues to stay the *same*, which means that when I get a support call about an issue, I *know* what is on the other end. On my servers, this issue is even more important. Another way to look at an LTS system can be by looking at time spent to administer the machine. An LTS machine is setup once, and while regular maintenance is done, that is, disk-space, logs, updates etc. are on-going, there is no time spent configuring software once the setup is completed. In terms of time, perhaps 10 minutes a week at most. I run a current stable machine as my workstation, so at the moment it's running Feisty. For me that's fine, I can update, compile, fix, etc. but I would never expect my users to do that. In terms of time spent maintaining it, I've upgraded from Dapper to Edgy, then from Edgy to Feisty, both in addition to the 10 minutes a week on normal maintenance. That means if I were to multiply that time investment across all my clients, one of us would go broke, either the client, or me. (Let alone the logistics of getting the updates to the client and rolling them out.) I will concede that there may be an argument for running an LTS machine that I am not aware of that is causing you to make your request. If so, please enlighten me. Otherwise I think you're using an LTS scenario for the wrong reasons and you should be running the current release. You should probably know that for years I ran Debian Testing because stable took too long - for me - to update and I needed newer functionality on my workstation. After Testing broke my machine one too many times, I switched to Ubuntu where there is a six-monthly release schedule that keeps me running the latest stuff without running into a random chance that my machine stops for no apparent reason after an update. (There are a few rough edges still, but I feel that everyone within Ubuntu is working to resolve that, including myself in small ways.) So, personally, I think that you're asking the wrong question. -- Onno Benschop Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |>>?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
> > > I run a current stable machine as my workstation, so at the moment it's > running Feisty. For me that's fine, I can update, compile, fix, etc. but > I would never expect my users to do that. In terms of time spent > maintaining it, I've upgraded from Dapper to Edgy, then from Edgy to > Feisty, both in addition to the 10 minutes a week on normal maintenance. > That means if I were to multiply that time investment across all my > clients, one of us would go broke, either the client, or me. (Let alone > the logistics of getting the updates to the client and rolling them out.) > > I will concede that there may be an argument for running an LTS machine > that I am not aware of that is causing you to make your request. If so, > please enlighten me. Otherwise I think you're using an LTS scenario for > the wrong reasons and you should be running the current release. > > I have not, and do not, in fact, run an LTS release. I've actually been running mostly Feisty, though I've been going back and forth between OSes as of late (OSX and Debian have been the others - though I may try FreeBSD next). My issue is basically that issues with hardware support pop up that are fixed after release (for example, my aforementioned suspend issue). As I said, most of the "Install Ubuntu on XYZ" articles include "compile X" or "install from unsupported repository Y". It seems like there is room for improvement here - most users would encounter a scenario like this and run. Getting updates like Firefox, etc was a secondary concern - though I still think there should be a way to do so simply within the package system. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Updating software between releases - where backports/SRU isn't enough
On 29/07/07 10:59, Tim Hull wrote: > My issue is basically that issues with hardware support pop up that > are fixed after release (for example, my aforementioned suspend issue). This issue looks simple enough "on the face of it", but as you will surely know, added support for a new piece of hardware comes at a cost. In some cases hardware is depreciated, or supported in another way. A PATA device might be implemented as IDE or as SCSI as new hardware support becomes available across newer releases of the kernel. This is why what you ask for is illogical in my opinion. An LTS release should be stable. You cannot expect and should not expect that an LTS release implements new functionality. You cannot expect that developers roll out support for a new gadget by backporting it into an older kernel in an attempt to support something new while retaining old expected behaviour. >From a support perspective, an LTS user needing support for a new gadget should in fact compile and install separately. If I am supporting such a machine, I should be aware of the "extra fix required" to be able to implement support for this new gadget that was released after LTS launch. > As I said, most of the "Install Ubuntu on XYZ" articles include > "compile X" or "install from unsupported repository Y". It seems like > there is room for improvement here - most users would encounter a > scenario like this and run. Getting updates like Firefox, etc was a > secondary concern - though I still think there should be a way to do > so simply within the package system. I'm not going anywhere near the notion of updating Firefox on an LTS. If you want that functionality, then there are backports and you should be on your own. Let me say again. The whole point of an LTS release is that it is stable. New hardware released after the launch of an LTS release should not be supported except in unusual circumstances. An LTS release should only ever have security and severe bugs applied. It is possible that you're agreeing with me, but that we're coming at this from a different angle. Kind regards, -- Onno Benschop Connected via Optus B3 at S31°54'06" - E115°50'39" (Yokine, WA) -- ()/)/)()..ASCII for Onno.. |>>?..EBCDIC for Onno.. --- -. -. --- ..Morse for Onno.. ITmaze - ABN: 56 178 057 063 - ph: 04 1219 - [EMAIL PROTECTED] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
