Hi,
Some people may not know that in Fedora 7, there was a difference between the DVD and the Live CD. What happened is (as far as I understand it) David Zeuthen took a look at things, and exercised a bit of editorial control by using the kickstart file - ship NetworkManager enabled by default, for example. This is exactly what Fedora as a desktop needs; a place for people who care about the experience as a desktop to do those quick fixes that may be hard to change in the Fedora base.
So, following a quick huddle with a few people from the Red Hat desktop team, we decided to make this LiveCD kickstart file a bit more of a project. Actually, the project already exists:
http://git.fedoraproject.org/?p=hosted/livecd;a=summary
So this mail is just to say that this project exists (and I know a lot of people didn't know about the difference), and will move forward. For Fedora 8, it would make sense to more prominently distinguish this version as the Desktop version.
Ideally of course, this project will be minimal - for example, the work to make NetworkManager usable on servers makes sense, and should continue.
On 7/27/07, Colin Walters walters@redhat.com wrote:
So, following a quick huddle with a few people from the Red Hat desktop team, we decided to make this LiveCD kickstart file a bit more of a project. Actually, the project already exists:
http://git.fedoraproject.org/?p=hosted/livecd;a=summary
So this mail is just to say that this project exists (and I know a lot of people didn't know about the difference), and will move forward. For Fedora 8, it would make sense to more prominently distinguish this version as the Desktop version.
Ideally of course, this project will be minimal - for example, the work to make NetworkManager usable on servers makes sense, and should continue.
I think running it as its own project is a great idea, and a perhaps a leading example of how to use individual livecd concepts as a vehicle for focused integration work.
You could think about making a strawman set of ideas for community people to poke at for integration back into the livecd. I think you could use the livecd project as a hook to generate new involvement by more desktop-centric community members.
-jef
Colin Walters wrote:
Hi,
Some people may not know that in Fedora 7, there was a difference between the DVD and the Live CD.
True. It was a FAQ that I answered in http://fedoraproject.org/wiki/Fedora7/FAQ
So this mail is just to say that this project exists (and I know a lot of people didn't know about the difference), and will move forward. For Fedora 8, it would make sense to more prominently distinguish this version as the Desktop version.
A sub project in Fedora has specific requirements since folks started announcing some in a semi random way. This is defined in http://fedoraproject.org/wiki/DefiningProjects.
Highlighting the desktop version would be primary be a website and documentation change. If anyone has good content, let the websites team know about that.
Rahul
On Sat, 2007-07-28 at 16:37 +0530, Rahul Sundaram wrote:
A sub project in Fedora has specific requirements since folks started announcing some in a semi random way. This is defined in http://fedoraproject.org/wiki/DefiningProjects.
Highlighting the desktop version would be primary be a website and documentation change. If anyone has good content, let the websites team know about that.
Right, though ideally this isn't a big formal project, just a place where we can tweak some defaults or the like. I think a lot depends on how much time is spent on it, but agreed that at this point it seems clear that we need to differentiate things better on the website at a minimum. Not sure what that text should say yet though...
Colin Walters wrote:
Right, though ideally this isn't a big formal project, just a place where we can tweak some defaults or the like. I think a lot depends on how much time is spent on it, but agreed that at this point it seems clear that we need to differentiate things better on the website at a minimum. Not sure what that text should say yet though...
When we say the Live images are desktop focused, what do we mean by that? Configuration changes like network manager by default, subset of Fedora that is good for desktop usage or something else?
Rahul
On Mon, 2007-07-30 at 13:48 +0530, Rahul Sundaram wrote:
Colin Walters wrote:
Right, though ideally this isn't a big formal project, just a place where we can tweak some defaults or the like. I think a lot depends on how much time is spent on it, but agreed that at this point it seems clear that we need to differentiate things better on the website at a minimum. Not sure what that text should say yet though...
When we say the Live images are desktop focused, what do we mean by that? Configuration changes like network manager by default, subset of Fedora that is good for desktop usage or something else?
Ok. In this discussion, one thing I'd like to keep in mind is that the technical fact that it's a "Live CD" or "Live Media" is not the interesting part. What is interesting is that it makes some attempt at choosing a target audience and defaults+tweaks for that target[1].
Maybe this means it's a spin. As Fedora seems to be going in the direction of making it easy for people to derive from Fedora, we could start to think in those terms.
Setting aside what to call it - I think the goal is to make a downloadable image that can be used as a start for:
1) Personal laptop internet terminal 2) Web developer workstation 3) Locked-down/managed lab terminal
Now, I think that 2) is basically a larger set of packages (wireshark, eclipse, icedtea, ruby, etc.) on top of 1). We should make it extremely easy to turn 1) into 2), because honestly I think that's where a lot of Fedora market share currently lies. 3) is interesting but those people can use the tools to make exactly what they want.
Even 1) is pretty vague, but it's at least an attempt at something. It gives us at least a guideline for figuring out what to include. For example, it makes it pretty obvious that packages like autofs and wireshark shouldn't be in the default package set.
[1] Unlike the DVD, which is a massive collection of software with lots of duplicated/unnecessary functionality that makes you choose mid-install (when you've already downloaded all of it) what to copy to your drive.
Colin Walters wrote:
Maybe this means it's a spin. As Fedora seems to be going in the direction of making it easy for people to derive from Fedora, we could start to think in those terms.
Right, the Fedora KDE live images are the Fedora KDE spin and it is messaged as such. Since we do multilib the x86_64 images happen to be more than CD size which I think we should avoid but that's another topic.
Setting aside what to call it - I think the goal is to make a downloadable image that can be used as a start for:
- Personal laptop internet terminal
- Web developer workstation
- Locked-down/managed lab terminal
Now, I think that 2) is basically a larger set of packages (wireshark, eclipse, icedtea, ruby, etc.) on top of 1). We should make it extremely easy to turn 1) into 2), because honestly I think that's where a lot of Fedora market share currently lies. 3) is interesting but those people can use the tools to make exactly what they want.
I think 1) is provided by the Fedora live images or alteast close to it. There has been some discussions from people who have installed from the live images but want the same setup as the default selection in the DVD and by that they probably want to do 2).
I am not sure how we are going to do 3) well. There is Sabayon and Pessulus in GNOME and Kiosk in KDE but they don't talk to each other and isn't really system wide. Some folks have been asking for similar software that they can use on internet cafe's. Atleast here some cafe's are migrating to Linux/Fedora because Microsoft has started enforcing their licensing and some businesses simple cannot afford the cost. That is a sort of a niche market that is growing.
Rahul
(Lalala... back from vacation, lots of mail.)
On Tue, 2007-07-31 at 20:13 -0400, Colin Walters wrote:
On Mon, 2007-07-30 at 13:48 +0530, Rahul Sundaram wrote:
Colin Walters wrote:
Right, though ideally this isn't a big formal project, just a place where we can tweak some defaults or the like. I think a lot depends on how much time is spent on it, but agreed that at this point it seems clear that we need to differentiate things better on the website at a minimum. Not sure what that text should say yet though...
When we say the Live images are desktop focused, what do we mean by that? Configuration changes like network manager by default, subset of Fedora that is good for desktop usage or something else?
Ok. In this discussion, one thing I'd like to keep in mind is that the technical fact that it's a "Live CD" or "Live Media" is not the interesting part. What is interesting is that it makes some attempt at choosing a target audience and defaults+tweaks for that target[1].
Exactly. And it's even less interesting to focus on it being a live CD as we're working towards having common formats being used to describe all of live images, a "tree spin", and even "installing from the everything tree".
That said, I think we're likely to want to target a live CD as the primary deployment/distribution vehicle.
Jeremy
Hi,
Sorry for the lag,
On Fri, 2007-07-27 at 12:04 -0400, Colin Walters wrote:
Some people may not know that in Fedora 7, there was a difference between the DVD and the Live CD. What happened is (as far as I understand it) David Zeuthen took a look at things, and exercised a bit of editorial control by using the kickstart file - ship NetworkManager enabled by default, for example. This is exactly what Fedora as a desktop needs; a place for people who care about the experience as a desktop to do those quick fixes that may be hard to change in the Fedora base.
Right. In fact, the Fedora Core 6 live cd had an even more narrow focus: only desktop users. I mean, just take a look at the delta between the F6 and F7 live CD:
http://www.redhat.com/archives/fedora-devel-list/2006-December/msg00469.html
Notable differences
- FC6 live CD was not installable; F7 live cd was
- FC6 live CD included more, uh, apps with a desktop focus that were not in the F7 live CD (due to lack of disc space) - Beagle, F-Spot, Inkscape, VPN tools (vpnc, openvpn)
- FC6 live CD omitted lots of things I don't think belongs in a default desktop install. Notably F7 live CD includes many of these things
- things like autofs, all of system-config-*
I was told at the time that "people except these things in a Fedora install". And I think that's the problem: that the target group of the F7 live cd is assumed to be any Fedora user instead of catering to desktop/laptop users. See below for more discussion.
Some explicit goals from the FC6 live CD were carried over though
- Universal Local support; e.g. abandon the "what languages do you need?" question during install. This includes
- Include enough fonts to have near 100% coverage of all the web pages in the world (http://wikipedia.org/ is a good test)
- Include all input methods; in fact, thanks to Warren Togami and others this was refined in F7 live cd to only start the Input Method applet if the locale needs it (e.g. avoid starting it in e.g. en_US and da_DK)
and in addition the F7 live cd is now installable which was a very big thing.
So this mail is just to say that this project exists (and I know a lot of people didn't know about the difference), and will move forward. For Fedora 8, it would make sense to more prominently distinguish this version as the Desktop version.
Right, I agree. The first thing that the Fedora project needs to address is making it easy for users to figure out what to download. Right now it's very confusing; just have a look at
http://fedoraproject.org/get-fedora.html
Instead, what we want is something like this
http://www.ubuntu.com/getubuntu/download
that actually guides people in downloading the right version. It could look like this
Fedora Desktop The perfect distribution tailored for both novice and seasoned desktop/laptop users. Featuring a network-less single-CD dead-simple install with a tasteful set of defaults chosen for you, you can always configure the system to your liking post-install.
Fedora KDE (put something here)
Fedora Universe Want to install a headless server or to an exotic system? Want to hand-tune the packages getting installed? Want to harness the power of scripting and fine-tuning system configuration? Want to do a network install? The Fedora Server is for you. It features both networked installs and updates. Perfect for the picky experts.
So we tell everyone to use "Fedora Desktop" instead. What's missing here is the upgrade story and our current story is "use anaconda to upgrade" which I think is pretty lame. We're asking people to go to d.fp.org (which already sucks) and make them download an ISO.
Clearly, technical problems aside, we simply *need* to have the package updater UI say "Hey, you're running Fedora N and Fedora N+1 is out. Press here to upgrade". How we solve that from a technical point of view, I don't care, but I _know_ it's technical feasible. Here's two suggestions
- "Just" fix yum, rpm and the way we do packaging / QA to actually make updating a live Fedora from version N to N+1 work. At least concede "it's a bug if it doesn't work" instead of saying "oh, that may not work; the official way is to use anaconda".
- Compute what RPM's are needed; download those. Provide a simple boot image that takes these RPM's and updates the base system. Poke grub.conf to boot into this. Ask user to reboot to complete the upgrade. System reboots into update image that simply updates the system. No user interaction. When update is complete, system reboots. Done.
I have a lot of thoughts about technical details and what set of packages should (and shouldn't) go on the Fedora Desktop Live CD. For example, I mean, a desktop system clearly don't need junk like system-config-keyboard or system-config-language since we don't care about the console. People who care about that stuff can install it later. So the main problem here is (lack of) *direction* and *messaging*. It's a social problem.
In other words, the Fedora Project (thus, the board), need to say "OK, we're actually doing a targeted Fedora Desktop product and people not using it for desktop/laptop can use the old 'Fedora Universe' way of doing things.". Until I see such leadership coming from the board I'm not sure it's worth messing around with kickstart files at all?
We, the people working on the Fedora Desktop, have this great chance to actually do a really good desktop distro. But as long as people expect "Fedora Live Media" to work in e.g. server use cases (as I argue they may do today, mainly due to bad messaging), it's just a waste of time IMNSHO. We need direction and razor sharp focus. We need the backing of the Fedora project and board to recognize that we're going to target *only* desktop users with the live media. We need to communicate that "Fedora Live Media" is *the* way to install the Desktop or KDE flavors of Fedora.
It's about direction and messaging. Fix that and we can do good stuff.
David
ps. Sorry if this mails came across as a rant.
On Wed, 2007-08-01 at 14:00 -0400, David Zeuthen wrote:
In other words, the Fedora Project (thus, the board), need to say "OK, we're actually doing a targeted Fedora Desktop product and people not using it for desktop/laptop can use the old 'Fedora Universe' way of doing things.". Until I see such leadership coming from the board I'm not sure it's worth messing around with kickstart files at all?
I don't think we need to wait for leadership necessarily, if there is interest in it. Let's make it work. If it does, then we can jump through whatever red tape is necessary.
We, the people working on the Fedora Desktop, have this great chance to actually do a really good desktop distro.
Right, because it's not actually that hard, as you (and whoever else that hacked on the livecd stuff) proved. It's just being willing to sit down and polish.
But as long as people expect "Fedora Live Media" to work in e.g. server use cases (as I argue they may do today, mainly due to bad messaging), it's just a waste of time
Totally agree.
Ok. Here's my suggestion. We call this "Fedora Personal Laptop". Skip the word "Desktop" because it means too many different things.
Personal Laptop is defined as targeting roughly the same base set of functionality that one might expect to find after purchasing a mainstream consumer laptop from Dell, Apple, HP, etc.
It is very explicitly *NOT* defined as a "Linux distribution" or "Fedora", because the first definition is and always has been meaningless, and the second is just vacuous/self-referential.
Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora".
On Wed, 2007-08-01 at 14:43 -0400, Colin Walters wrote:
Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora".
As important as your goals are, denigrating the people who put the whole distribution together with this last remark is unnecessary and unhelpful.
There's no need for divisiveness. What you're working on does not preclude the work that makes it possible for you to do that.
-sv
On Wed, 2007-08-01 at 14:45 -0400, seth vidal wrote:
On Wed, 2007-08-01 at 14:43 -0400, Colin Walters wrote:
Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora".
As important as your goals are, denigrating the people who put the whole distribution together with this last remark is unnecessary and unhelpful.
You are right, and I apologize! It was not just unnecessary but wrong. I got too worked up into things for sure.
On Wed, 01 Aug 2007 14:43:13 -0400 Colin Walters walters@redhat.com wrote:
Ok. Here's my suggestion. We call this "Fedora Personal Laptop". Skip the word "Desktop" because it means too many different things.
Personal Laptop is defined as targeting roughly the same base set of functionality that one might expect to find after purchasing a mainstream consumer laptop from Dell, Apple, HP, etc.
It is very explicitly *NOT* defined as a "Linux distribution" or "Fedora", because the first definition is and always has been meaningless, and the second is just vacuous/self-referential.
Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora".
I would love to see something like this, even by Test2 if possible. I'd even be willing to make our 'default' Live image we ship this, instead of a Live version of the "Fedora" spin (whatever the heck that's supposed to mean).
On Wed, 2007-08-01 at 14:46 -0400, Jesse Keating wrote:
On Wed, 01 Aug 2007 14:43:13 -0400 Colin Walters walters@redhat.com wrote:
Ok. Here's my suggestion. We call this "Fedora Personal Laptop". Skip the word "Desktop" because it means too many different things.
Personal Laptop is defined as targeting roughly the same base set of functionality that one might expect to find after purchasing a mainstream consumer laptop from Dell, Apple, HP, etc.
It is very explicitly *NOT* defined as a "Linux distribution" or "Fedora", because the first definition is and always has been meaningless, and the second is just vacuous/self-referential.
Does this mean Personal Laptop is actually defined as chasing the tail of competitors? Yes, it does. Is there something wrong with that? Well, it's a lot better than just shipping a gigantic DVD or a mishmash of whatever random package developers thought needs to be in "Fedora".
I would love to see something like this, even by Test2 if possible. I'd even be willing to make our 'default' Live image we ship this, instead of a Live version of the "Fedora" spin (whatever the heck that's supposed to mean).
[walters@neutron livecd]$ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: config/livecd-fedora-desktop.ks -> config/livecd-fedora-personal.ks #
For now, in here: http://submind.verbum.org/~walters/livecd.git/
I haven't looked whether the package set is sane for fedora-personal.ks. I did verify it boots. Basically I just did some infrastructure work so that I could create an online-desktop livecd without creating yet another fork of a big kickstart file.
It's a start!
An immediate interesting task for the fedora-personal.ks would be seeing how hard it would be to fit say OpenOffice, now that we know we can drop things like sendmail, etc.
Colin Walters (walters@redhat.com) said:
An immediate interesting task for the fedora-personal.ks would be seeing how hard it would be to fit say OpenOffice, now that we know we can drop things like sendmail, etc.
If you intend to keep to the 'single-image-for-all-languages' goal, and still have it fit on a CD... isn't going to happen.
Bill
On Wed, 2007-08-01 at 15:03 -0400, Colin Walters wrote:
An immediate interesting task for the fedora-personal.ks would be seeing how hard it would be to fit say OpenOffice, now that we know we can drop things like sendmail, etc.
Just looked at the ubuntu livecd recently, has OOo on it and the gimp, the ubuntu gimp doesn't ask anything during first install. So it might be neat for the livecd/personal cd to include pre-canned .gimp-2.2/.openoffice.org2 config directories for the livecd ~/home to avoid the very first-start up time hit/config questions for the livecds
C.
On Thu, 02 Aug 2007 08:38:45 +0100 Caolan McNamara caolanm@redhat.com wrote:
Just looked at the ubuntu livecd recently, has OOo on it and the gimp, the ubuntu gimp doesn't ask anything during first install. So it might be neat for the livecd/personal cd to include pre-canned .gimp-2.2/.openoffice.org2 config directories for the livecd ~/home to avoid the very first-start up time hit/config questions for the livecds
As stated elsewhere, having all languages as a goal and having OO.org as a goal are in direct conflict. oo.org+translations is over 700 megs itself.
Jesse Keating wrote:
On Thu, 02 Aug 2007 08:38:45 +0100 Caolan McNamara caolanm@redhat.com wrote:
Just looked at the ubuntu livecd recently, has OOo on it and the gimp, the ubuntu gimp doesn't ask anything during first install. So it might be neat for the livecd/personal cd to include pre-canned .gimp-2.2/.openoffice.org2 config directories for the livecd ~/home to avoid the very first-start up time hit/config questions for the livecds
As stated elsewhere, having all languages as a goal and having OO.org as a goal are in direct conflict. oo.org+translations is over 700 megs itself.
for x86_64 we already use a dvd ... so why not add OO ?
On Thu, 2007-08-02 at 13:40 +0200, dragoran wrote:
for x86_64 we already use a dvd ... so why not add OO ?
It's been a goal, earlier, to produce a distribution that fits on a CD for all the usual reasons: DVD media is more expensive, not everyone has DVD burners, some people don't even have DVD readers.
Btw, some of us consider the goal of having multilib on the x86_64 desktop live cd wrong. I'm sure it makes a lot of sense for general Fedora users (especially those using an enterprise rebuild, *cough*, RHEL) but am not so sure that the segment we're trying to target really cares. And if they do care, our package management tools should be able to pull in the 32-bit requisite packages anyway (and I think the tools support this already).
The latter is just one example of where we perhaps have to depart from traditional thinking. Historically it has caused a lot of friction and flame wars mainly because we've tried to please everyone with a single distribution called Fedora.
By having a much tighter focus we need to revisit some our goals. This includes goals like "is it important it fits on CD media", "should we include all locales or have regional variants", "do we support multi-lib out of the box". I don't know what the answer is to any of these. At least it's worth thinking about.
David
David Zeuthen wrote:
On Thu, 2007-08-02 at 13:40 +0200, dragoran wrote:
for x86_64 we already use a dvd ... so why not add OO ?
It's been a goal, earlier, to produce a distribution that fits on a CD for all the usual reasons: DVD media is more expensive, not everyone has DVD burners, some people don't even have DVD readers.
I doubt you will find a many *x86_64* boxes without dvd readers (or even burners).
Btw, some of us consider the goal of having multilib on the x86_64 desktop live cd wrong.
I disagre here people want third party apps to run out of the box and some of them are not shipped as x86_64 versions the best examples are flash and closed sources games like quake4.
I'm sure it makes a lot of sense for general Fedora users (especially those using an enterprise rebuild, *cough*, RHEL) but am not so sure that the segment we're trying to target really cares. And if they do care, our package management tools should be able to pull in the 32-bit requisite packages anyway (and I think the tools support this already).
if its about installing packages its true and they indeed gets pulled in. but still basic multilib support is needed for cases like I mentioned above.
[..] I don't know what the answer is to any of these. At least it's worth thinking about.
+1
On Thu, 2007-08-02 at 07:51 -0400, David Zeuthen wrote:
By having a much tighter focus we need to revisit some our goals.
Just for historical background of a few of these (not saying we shouldn't revisit them, but so everyone starts on the same page so to speak)
This includes goals like "is it important it fits on CD media",
Feedback from non-US/non-European based locales is that CD media is still very important. The fact that the "Fedora spin" is DVD only gets a reasonable amount of flak, but it tends to be deflected with "go use the live CD" :)
"should we include all locales or have regional variants",
Regional variants implies a need for more storage and more testing time. That's the historical thinking anyway
"do we support multi-lib out of the box".
The processor vendors are *huge* fans of this and users _who take advantage of it_ are also. The argument is that without the 32bit-ness available and there with no intervention needed, you might as well switch to a different arch altogether.
Jeremy
Jeremy Katz wrote:
Feedback from non-US/non-European based locales is that CD media is still very important. The fact that the "Fedora spin" is DVD only gets a reasonable amount of flak, but it tends to be deflected with "go use the live CD" :)
That doesn't always work. We have got several dozen people asking about this despite the presence of installable live images.
1) There are people who want access to a large number of packages but don't have a high bandwidth connection or DVD drive. Lack of full media support in yum and friends makes it hard too. Integrating Jidgo into the release process might be useful for them. Also Opyum.
2) On x86_64 you have to use special CD media or usually DVD but you don't get all the packages you could fill in a DVD. If you want to continue insisting on multi-lib by default then a better solution might be to cut down on the x86 image size so that the x86_64 image still fits on a CD.
3) We haven't yet worked out a good upgrade solution for those who have installed from a live image. If you get the anaconda based semi live upgrade solution before Fedora 8 release, we should be ok.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
- On x86_64 you have to use special CD media or usually DVD but you don't
get all the packages you could fill in a DVD. If you want to continue insisting on multi-lib by default then a better solution might be to cut down on the x86 image size so that the x86_64 image still fits on a CD.
I don't understand this... you have a DVD burner/reader but now *media* is a problem?
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
- On x86_64 you have to use special CD media or usually DVD but you don't
get all the packages you could fill in a DVD. If you want to continue insisting on multi-lib by default then a better solution might be to cut down on the x86 image size so that the x86_64 image still fits on a CD.
I don't understand this... you have a DVD burner/reader but now *media* is a problem?
Wasn't talking about myself but there are a number of x86_64 systems (and want the x86_64 version of Fedora ) without a DVD drive out there. If they don't have a high bandwidth connection it is tricky for them to do a installation of Fedora 7. You could copy DVD drive to a separate partition and do a hard disk installation but I don't think that should be the only way.
Rahul
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Wasn't talking about myself but there are a number of x86_64 systems (and want the x86_64 version of Fedora ) without a DVD drive out there.
Surely you mean 'without an optical drive'.
Are you referring to things like USB?
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
Wasn't talking about myself but there are a number of x86_64 systems (and want the x86_64 version of Fedora ) without a DVD drive out there.
Surely you mean 'without an optical drive'.
Are you referring to things like USB?
I'm saying anything new enough to be x86_64 that has an optical drive is reasonably new enough to have a DVD-ROM.
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
Wasn't talking about myself but there are a number of x86_64 systems (and want the x86_64 version of Fedora ) without a DVD drive out there.
Surely you mean 'without an optical drive'.
Are you referring to things like USB?
I'm saying anything new enough to be x86_64 that has an optical drive is reasonably new enough to have a DVD-ROM.
People keep saying that but end users are repeating coming up with instances where this isn't true at all. I just pointed this out to Jeremy earlier.
https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.ht...
Follow fedora-list discussions or fedoraforum.org for more such instances.
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.ht...
That message does not contradict my point in any way. Please read carefully.
Bill
Bill Nottingham wrote:
Rahul Sundaram (sundaram@fedoraproject.org) said:
https://www.redhat.com/archives/fedora-websites-list/2007-August/msg00020.ht...
That message does not contradict my point in any way. Please read carefully.
He has a x86_64 system with only a CD-RW drive which does seem to contradict what you said to me. How do you recommend that he install Fedora 7 if he doesn't have a high bandwidth connection?
Rahul
Rahul Sundaram (sundaram@fedoraproject.org) said:
He has a x86_64 system with only a CD-RW drive which does seem to contradict what you said to me. How do you recommend that he install Fedora 7 if he doesn't have a high bandwidth connection?
His *burner* box isn't DVD - we realize we don't serve that market any way, and that's what the media projects are for.
Bill
On Thu, 2007-08-02 at 07:34 -0400, Jesse Keating wrote:
On Thu, 02 Aug 2007 08:38:45 +0100 Caolan McNamara caolanm@redhat.com wrote:
Just looked at the ubuntu livecd recently, has OOo on it and the gimp, the ubuntu gimp doesn't ask anything during first install. So it might be neat for the livecd/personal cd to include pre-canned .gimp-2.2/.openoffice.org2 config directories for the livecd ~/home to avoid the very first-start up time hit/config questions for the livecds
As stated elsewhere, having all languages as a goal and having OO.org as a goal are in direct conflict. oo.org+translations is over 700 megs itself.
Seems unfortunate that we can't use the livecd for e.g. emergency use for playing impress presentations because the total size for its translations would be too large.
Blocking on "all OOo translations won't fit, so we must only pick apps whose complete translations fit" seems a little like cheating though. i.e. Abiword seems to have its help translated to just English, French and German, while Gnumeric seems to have just English(?) help and approx 15+ less translations than OOo.
Sure, if the non-translated bits are fundamentally overscale to fit on cd vs the other options, or its too slow to run from CD, or we hate it too much to want it, then that's fine. But if the reason boiled down to solely having all languages supported on the cd as a goal and apps are then picked that have less translation coverage due to space reasons then that strikes me as a bit of a fudge.
C.
On Thu, 02 Aug 2007 13:33:28 +0100 Caolan McNamara caolanm@redhat.com wrote:
Sure, if the non-translated bits are fundamentally overscale to fit on cd vs the other options, or its too slow to run from CD, or we hate it too much to want it, then that's fine. But if the reason boiled down to solely having all languages supported on the cd as a goal and apps are then picked that have less translation coverage due to space reasons then that strikes me as a bit of a fudge.
I don't disagree. However it's a lot easier to say "we don't support your language because there was no translation for it upstream" than to say "we don't support your language because we didn't think it was important enough to include on the media. Sorry.".
Still, some thought could be put around having regional editions of the live image that include a set of the languages for that region or some other ideas such as that. It just takes somebody playing around with it (: The good news is that the tools are relatively easy so that those playing at home can try things out instead of waiting for something to fall out of the Red Hat black box.
On Thu, 2007-08-02 at 09:36 -0400, Jesse Keating wrote:
On Thu, 02 Aug 2007 13:33:28 +0100 Caolan McNamara caolanm@redhat.com wrote:
Sure, if the non-translated bits are fundamentally overscale to fit on cd vs the other options, or its too slow to run from CD, or we hate it too much to want it, then that's fine. But if the reason boiled down to solely having all languages supported on the cd as a goal and apps are then picked that have less translation coverage due to space reasons then that strikes me as a bit of a fudge.
I don't disagree. However it's a lot easier to say "we don't support your language because there was no translation for it upstream" than to say "we don't support your language because we didn't think it was important enough to include on the media. Sorry.".
Still, some thought could be put around having regional editions of the live image that include a set of the languages for that region or some other ideas such as that. It just takes somebody playing around with it (: The good news is that the tools are relatively easy so that those playing at home can try things out instead of waiting for something to fall out of the Red Hat black box.
+1. A while back gnome made a gnome preview live cd. It was a version of the gnome using an ubuntu livecd. They did one for the various languages that wanted them - hitting most of the 'major' languages and then doing others on request.
-sv
On 8/2/07, seth vidal skvidal@fedoraproject.org wrote:
+1. A while back gnome made a gnome preview live cd. It was a version of the gnome using an ubuntu livecd. They did one for the various languages that wanted them - hitting most of the 'major' languages and then doing others on request.
on request...... sounds like the perfect job for wevisor, and its template archive. http://publictest1.fedora.redhat.com/wevisor/
-jef"did i mention that wevisor looks like its going to kick ass"spaleta
On Thu, 2007-08-02 at 09:36 -0400, Jesse Keating wrote:
On Thu, 02 Aug 2007 13:33:28 +0100 Caolan McNamara caolanm@redhat.com wrote:
Still, some thought could be put around having regional editions of the live image that include a set of the languages for that region or some other ideas such as that.
Yeah, that's where I was going, a single global cd is tricky in the long run even excluding OOo. We currently get away with it because we're not generally massively translated, except for poor OOo, and even there I'm already skipping building about 18 languages which don't have any have existing support in the rest of our desktop e.g having no available free fonts to display the language or it would be the only translated application into that language. I'd well imagine that if the existing set of software gets translated to the same extent that we'd have trouble fitting in onto a cd :-(
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
C.
On 8/2/07, Caolan McNamara caolanm@redhat.com wrote:
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
Are all the translations broken out into subpackages in sane way across the distro? Or is there re-packaging work that needs to be done to make it possible to respin regionally? Are there any other major roadblocks to someone making a regional cd right now using something like revisor?
I think regional cds are the way to go, but I'm not sure its appropriate to change policy in terms of how we handle translations for the F8 timescale. I think we could probably decide...soon-ish..that we want to go regional for F9, and start prioritizing the work to get from here to there. That would also give "us" some time to have solid discussions with the non-EN/US speakers about jumping on board to help create the re-spins.
-jef
Jeff Spaleta (jspaleta@gmail.com) said:
On 8/2/07, Caolan McNamara caolanm@redhat.com wrote:
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
Are all the translations broken out into subpackages in sane way across the distro?
For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.)
Bill
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.)
Is there a fundamental technology shift that we have to swallow? Or is it more a death by a thousand cuts if we go in and start package surgery? For crap that has a lot of translation coverage, then it becomes more important an issue. I'll rephrase the question, if we decided that a single package needed to have its translations split off.. is there a known set of things that need to be adjusted? And do we have an idea what the next largest package is that would add additional flexibility for regional cd creation?
it's never easy...but is it too hard to do by F9? I think if we are serious about focusing, then livecds are the best vechicle we have to explore focused space, in a way that gives external community a chance to help define cool foci. And if we can get to the point where regional cds are possible, that will significantly add in our flexibility moving forward.
-jef"Penalizing openoffice because it does have significant translation support is a little ass-backwards."spaleta
Jeff Spaleta (jspaleta@gmail.com) said:
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.)
Is there a fundamental technology shift that we have to swallow? Or is it more a death by a thousand cuts if we go in and start package surgery?
The issue is that as soon as you split the package, you end up having to track both all the splits of that package and the union of all languages that have translations manually in comps for all releases where you may have that package. Moreover, users cannot easily add these languages later to their system.
If you do not split, all these problems go away.
Bill
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
If you do not split, all these problems go away.
so fundamental technology issue. We can't duck this forever. I if the new kick ass localization project does their job.. you'll have to deal with this sooner than later when the perfect future of all applications with full translation support walks up and steals your lunch money. If we had full translation support for everything in the repository, how functional would a desktop oriented livecd actually be?
-jef
On Thu, 2 Aug 2007 08:59:07 -0800 "Jeff Spaleta" jspaleta@gmail.com wrote:
I'll rephrase the question, if we decided that a single package needed to have its translations split off.. is there a known set of things that need to be adjusted?
Lots and lots more conditionals in comps, and making sure that everything that groks comps really does conditionals well, and that is a hard path. (conditionals are difficult to get right)
On Thu, 2007-08-02 at 12:14 -0400, Bill Nottingham wrote:
Jeff Spaleta (jspaleta@gmail.com) said:
On 8/2/07, Caolan McNamara caolanm@redhat.com wrote:
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
Are all the translations broken out into subpackages in sane way across the distro?
For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.)
%{lang} tagging is simple enough to take advantage of with the live images if we want. Just needs a) way to specify it (return of langsupport!) and b) then actually setting the rpm macro.
You're kind of screwed if you ever want to add more translations, but that is a tradeoff that could be made. But the discussion about that is going on in a different thread too :-)
Jeremy
On Tue, 2007-08-07 at 14:05 -0400, Jeremy Katz wrote:
On Thu, 2007-08-02 at 12:14 -0400, Bill Nottingham wrote:
Jeff Spaleta (jspaleta@gmail.com) said:
On 8/2/07, Caolan McNamara caolanm@redhat.com wrote:
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
Are all the translations broken out into subpackages in sane way across the distro?
For OO.o and KDE, they are split. For other packages, they are not. Whether to split or not is a long, drawn-out conversation. (Basically, you make building liveCDs easier at the cost of making all languages Just Work much harder.)
%{lang} tagging is simple enough to take advantage of with the live images if we want. Just needs a) way to specify it (return of langsupport!) and b) then actually setting the rpm macro.
I think it would be worthwhile to investigate this some more. I've started to add %lang tagging to all the big translated manuals in gnome packages, which should make this quite a bit more effective.
On Tue, 2007-08-07 at 14:05 -0400, Jeremy Katz wrote:
%{lang} tagging is simple enough to take advantage of with the live images if we want. Just needs a) way to specify it (return of langsupport!) and b) then actually setting the rpm macro.
You're kind of screwed if you ever want to add more translations, but that is a tradeoff that could be made. But the discussion about that is going on in a different thread too :-)
After Panu showed the necessary queryformat magic in the other thread, I actually sat down to see how hard it is to get the necessary information out of rpm to do that. The result is a very rough shell script that spits out a list of packages that you need to reinstall when _install_langs changes. This is just a proto-prototype:
- You can probably do the same thing much better in python
- A real solution must handle language support groups as well
- I don't know if this approach will work for removal of languages, too. (Does --replacepkg ever remove files ?)
- It would probably be better to use a dedicated /etc/rpm/macros.lang file
- An actual implementation must decide where to expose this functionality: in pirut, since it is about installing packages or in s-c-language, since it is about language support ?
Maybe this inspires somebody to work on an actual implementation.
Matthias
On 8/2/07, Jeff Spaleta jspaleta@gmail.com wrote:
[...] That would also give "us" some time to have solid discussions with the non-EN/US speakers about jumping on board to help create the re-spins.
creating spins for _each_ language is overkill we can have more than one on a cd.
On 8/2/07, dragoran drago01@gmail.com wrote:
creating spins for _each_ language is overkill we can have more than one on a cd.
Yes of course... regions.
-jef"dreams of a day when Fedora can have a livecd for all indigenous North American Arctic languages. I really need to talk to the language center here on campus."spaleta
On Thu, 2007-08-02 at 08:12 -0800, Jeff Spaleta wrote:
On 8/2/07, Caolan McNamara caolanm@redhat.com wrote:
Most companies have the luxury of a formal or informal big 7 or big 12 language policy, and e.g. Dzongkha and Irish can forget about being supported. I guess the ideal solution for something like fedora would be a set of regional cds, though I'm not enthusiastic about actually contributing constructively and doing the work :-)
Are all the translations broken out into subpackages in sane way across the distro? Or is there re-packaging work that needs to be done to make it possible to respin regionally? Are there any other major roadblocks to someone making a regional cd right now using something like revisor?
I think regional cds are the way to go, but I'm not sure its appropriate to change policy in terms of how we handle translations for the F8 timescale. I think we could probably decide...soon-ish..that we want to go regional for F9, and start prioritizing the work to get from here to there. That would also give "us" some time to have solid discussions with the non-EN/US speakers about jumping on board to help create the re-spins.
Wouldn't you use the rpm mechanism to install a subset of languages for that ?
Matthias Clasen (mclasen@redhat.com) said:
Wouldn't you use the rpm mechanism to install a subset of languages for that ?
If we set the lang tsflags in the yum process creating the FS for the livecd... this could theoretically work. Without splitting the packages. Which is good.
Bill
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
If we set the lang tsflags in the yum process creating the FS for the livecd... this could theoretically work. Without splitting the packages. Which is good.
So doom avoided... theoretically?
-jef
On Thu, 2007-08-02 at 09:34 -0800, Jeff Spaleta wrote:
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
If we set the lang tsflags in the yum process creating the FS for the livecd... this could theoretically work. Without splitting the packages. Which is good.
So doom avoided... theoretically?
However, this way of doing things won't allow you to extra language support later. Unless someone builds technology to do this. It may not be a big problem.
David
On Thu, 2007-08-02 at 13:46 -0400, David Zeuthen wrote:
On Thu, 2007-08-02 at 09:34 -0800, Jeff Spaleta wrote:
On 8/2/07, Bill Nottingham notting@redhat.com wrote:
If we set the lang tsflags in the yum process creating the FS for the livecd... this could theoretically work. Without splitting the packages. Which is good.
So doom avoided... theoretically?
However, this way of doing things won't allow you to extra language support later. Unless someone builds technology to do this. It may not be a big problem.
Sounds like a solvable problem. rpm would have to keep track of which packages have been installed with a restricted set of languages, and then reinstall them if the set of installed languages changes later. Or something like that.
Colin Walters wrote:
Ok. Here's my suggestion. We call this "*Fedora Personal Laptop*". Skip the word "Desktop" because it means too many different things.
This is a awfull name. If you call it "Laptop" only people who use/have laptops will download and use it. But it should be targeted at _desktop_ users .. so whats wrong with the name desktop? You can do atleast s/Laptop/Desktop/
On Thu, 2007-08-02 at 10:22 +0200, dragoran wrote:
Colin Walters wrote:
Ok. Here's my suggestion. We call this "*Fedora Personal Laptop*". Skip the word "Desktop" because it means too many different things.
This is a awfull name. If you call it "Laptop" only people who use/have laptops will download and use it. But it should be targeted at _desktop_ users .. so whats wrong with the name desktop? You can do atleast s/Laptop/Desktop/
I don't actually care a lot about the name - if consensus seems to be in favor of Desktop that's fine.
On 8/2/07, Colin Walters walters@redhat.com wrote:
I don't actually care a lot about the name - if consensus seems to be in favor of Desktop that's fine.
Perhaps it would be better to avoid the laptop/desktop/server language entirely.
Fedora Workspace CD? "Get working now" Fedora Now CD? Fedora On-the-Go CD? "Always on the move with Fedora" Fedora Essentials CD? "Essentials for everyday computing...anywhere"
-jef
On Thu, 2007-08-02 at 10:16 -0800, Jeff Spaleta wrote:
On 8/2/07, Colin Walters walters@redhat.com wrote:
I don't actually care a lot about the name - if consensus seems to be in favor of Desktop that's fine.
Perhaps it would be better to avoid the laptop/desktop/server language entirely.
I more and more think there's a lot of validity to this line of thinking...
Fedora Workspace CD? "Get working now" Fedora Now CD? Fedora On-the-Go CD? "Always on the move with Fedora" Fedora Essentials CD? "Essentials for everyday computing...anywhere"
I kind of like the last one. But what the hell do I know? :-)
Jeremy
David Zeuthen wrote:
In other words, the Fedora Project (thus, the board), need to say "OK, we're actually doing a targeted Fedora Desktop product and people not using it for desktop/laptop can use the old 'Fedora Universe' way of doing things.". Until I see such leadership coming from the board I'm not sure it's worth messing around with kickstart files at all?
I am not sure if you have seen the the long thread on fedora advisory board list on what the target market is.
Take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2821
There is also a article at http://lwn.net/SubscriberLink/242965/c8ef393b828b04e8/
I would highly recommend writing down a proposal and send to the advisory board list. If you or anyone as a team want to lead this effort, it is likely the board will accept that.'
Waiting for this to happen on its own somehow is unlikely to work.
Rahul
On Thu, 2007-08-02 at 00:29 +0530, Rahul Sundaram wrote:
David Zeuthen wrote:
In other words, the Fedora Project (thus, the board), need to say "OK, we're actually doing a targeted Fedora Desktop product and people not using it for desktop/laptop can use the old 'Fedora Universe' way of doing things.". Until I see such leadership coming from the board I'm not sure it's worth messing around with kickstart files at all?
I am not sure if you have seen the the long thread on fedora advisory board list on what the target market is.
Take a look at http://thread.gmane.org/gmane.linux.redhat.fedora.advisory-board/2821
There is also a article at http://lwn.net/SubscriberLink/242965/c8ef393b828b04e8/
I would highly recommend writing down a proposal and send to the advisory board list. If you or anyone as a team want to lead this effort, it is likely the board will accept that.'
Waiting for this to happen on its own somehow is unlikely to work.
There is no need to wait for anything, as Colin said. Or to apply for approval to any superiors. We just need to do it. And we will.
Matthias Clasen wrote:
There is no need to wait for anything, as Colin said. Or to apply for approval to any superiors. We just need to do it. And we will.
Talking to the board doesn't really equate to "approval to superiors". David Zuethen said he wanted the board to acknowledge that and I do think you need project wide support to do something like this efficiently instead of continuing to do something as a closed group. If you can just do it, more power to you but let people know what you have planned including positioning the live images as the desktop spin.
Rahul
On Thu, 2007-08-02 at 00:46 +0530, Rahul Sundaram wrote:
Matthias Clasen wrote:
There is no need to wait for anything, as Colin said. Or to apply for approval to any superiors. We just need to do it. And we will.
Talking to the board doesn't really equate to "approval to superiors". David Zuethen said he wanted the board to acknowledge that and I do think you need project wide support to do something like this efficiently instead of continuing to do something as a closed group.
Just stop the "closed group" mantra, please. We are discussing this on a public mailing list.
Matthias Clasen wrote:
On Thu, 2007-08-02 at 00:46 +0530, Rahul Sundaram wrote:
Matthias Clasen wrote:
There is no need to wait for anything, as Colin said. Or to apply for approval to any superiors. We just need to do it. And we will.
Talking to the board doesn't really equate to "approval to superiors". David Zuethen said he wanted the board to acknowledge that and I do think you need project wide support to do something like this efficiently instead of continuing to do something as a closed group.
Just stop the "closed group" mantra, please. We are discussing this on a public mailing list.
Yes this is a public list and it is desktop specific and it was pretty much dead for a few releases. This is not a place to get project wide support. If desktop team is a SIG and acting in the open, I would able to find the list of members, lead etc but like I said before things have improved more than before.
Rahul
Rahul Sundaram wrote:
Matthias Clasen wrote:
Just stop the "closed group" mantra, please. We are discussing this on a public mailing list.
Yes this is a public list and it is desktop specific and it was pretty much dead for a few releases. This is not a place to get project wide support.
Rahul, There are many contributors on this list, including non Red Hat employees, and several board members are keenly following threads here.
If desktop team is a SIG and acting in the open, I would able to find the list of members, lead etc but like I said before things have improved more than before.
So in order to be open one needs to have a SIG? That means that countless "open" source projects really aren't because they don't have SIGs or list their full membership? Seriously. Stop. Adding false conflict only serves to harm the project as a whole.
Christopher Aillon wrote:
Rahul Sundaram wrote:
Matthias Clasen wrote:
Just stop the "closed group" mantra, please. We are discussing this on a public mailing list.
Yes this is a public list and it is desktop specific and it was pretty much dead for a few releases. This is not a place to get project wide support.
Rahul, There are many contributors on this list, including non Red Hat employees, and several board members are keenly following threads here.
I don't understand the amount of resistance in following any process at all and providing feedback where it matters. If you want the board to do something, then communicate what you want to them. Is that a big deal?
So in order to be open one needs to have a SIG?
Nope but in Fedora if there is a team working together on something it would be usually easy to atleast find out who the members are. How do I find out who the members are in the desktop team? Who is making the decisions and where are they making it in all the previous releases? A SIG or sub project is how people organize together in Fedora.
All the work on the desktop in Fedora does goes without any visibility and I have already talked to various members about this problem in the past. Getting defensive is not going to solve it. You merely end up shooting the messenger.
Rahul
On Wed, 2007-08-01 at 14:00 -0400, David Zeuthen wrote:
I mean, just take a look at the delta between the F6 and F7 live CD: Notable differences
[some snipping]
- FC6 live CD included more, uh, apps with a desktop focus that were not in the F7 live CD (due to lack of disc space)
- Beagle, F-Spot, Inkscape, VPN tools (vpnc, openvpn)
FWIW, the vast majority of your list here wasn't due to space. Beagle was because we disabled beagle _in general_ for the desktop[1]. f-spot just isn't the default photo app -- if it should be, let's swap it and gthumb in comps. VPN tools was just an omission as I thought I had fixed it but apparently I suck ;-)
Inkscape is really the only one that was driven off purely from a space perspective.
[snip]
So we tell everyone to use "Fedora Desktop" instead. What's missing here is the upgrade story and our current story is "use anaconda to upgrade" which I think is pretty lame. We're asking people to go to d.fp.org (which already sucks) and make them download an ISO.
A lot of the work for improving this is based on one of the fedora-devel threads is underway. Basically, an app you can run to download the packages and set everything up to reboot you into the installer to do the actual upgrade. Need to do a little bit more experimentation to prove things out, but it's looking somewhat promising. (Note to self: need to do the feature write-up for it). Once we've had it working for a release or so, wiring in a "hey, there's a new version available" thing pop up is definitely doable.
[more snipping]
I have a lot of thoughts about technical details and what set of packages should (and shouldn't) go on the Fedora Desktop Live CD. For example, I mean, a desktop system clearly don't need junk like system-config-keyboard or system-config-language since we don't care about the console.
Actually, for these, the bigger problem is that some of our tools (like the installer) depends on them being there as we decided to actually make things modular and reuse components. Damned when we do, damned when we don't. Can probably do something to make those requirements fall back to just "figuring things out" when they're not there and not doing the questions. At the same time, all of system-config-* is < 15 megs. And once you take out the stuff not on the livecd (bind, network can go once NetworkManager can configure dial-up, kickstart, soundcard, ..) we're talking about 3 megs. So maybe not a big win although if someone wants to work on the anaconda patch, I'd be glad to review it and get it committed.
Jeremy
[1] Note, beagle has other annoying characteristics when being used with the liveCD in that it starts indexing the world chewing up memory for its indices which then have to be redone all the time. Also, lots of CD seeking...
desktop@lists.stg.fedoraproject.org
-
Bill Nottingham -
Caolán McNamara -
Christopher Aillon -
Colin Walters -
David Zeuthen -
drago01 -
Jef Spaleta -
Jeremy Katz -
Jesse Keating -
Matthias Clasen -
Rahul Sundaram -
Seth Vidal