From gmureddu at prodigy.net.mx Fri Sep 1 01:26:36 2006 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Thu, 31 Aug 2006 20:26:36 -0500 Subject: usability: fedora's killer app? Clean-Install Assistant... In-Reply-To: <604aa7910608311147q10abe878i8d570a8c59f414a5@mail.gmail.com> References: <44F6CE7E.5020509@read.org.nz> <"604aa7910608311147q10abe878i8d570 a8c59f414a5"@mail.gmail.com> Message-ID: <44F78C4C.9080108@prodigy.net.mx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What about this scenario: * Start installation process of the new release. * Upon detection of your existing copy of Fedora, prompt the user to migrate user information, accounts, etc. ? If clean installation is selected offer at least two options: - Format current partition layout. - Keep personal files and account/system layout (fstab) information. ? Proceed according to options with the disks, in case of unallocated partitions (as per fstab) and usable partitions found, prompt the user if he/she would like to start disk druid to allocate/format/etc those partitions or stick to the migrated fstab layout and doing the allocation later. * Select packages, mirrors, etc * Boot your system, and make first boot inherit system accounts information. In oder words, if there is something "nonstandard" on /etc/shadow and /etc/group, and they correlate to the users in /home, skip the user creation step. Basically instead of full reformat, what would be done is something like a 'for in' loop to remove all system files, except for those needed to perform the migration, i.e /home (in case of a monolithic /, and if there's a /home entry as a mountpoint in fstab, ignore this), /etc/shadow, /etc/group, /etc/passwd. Perform the installation, and if users in /etc/passwd do match the declaration of their home directories, make First Boot skip user creation. It would also be helpful to be able to asign root's password as part of the First Boot service, especially helpful if you sell systems with Fedora pre-installed, you can kick-start the systems for installation, and the end user is able to set their own root password as part of the first boot configuration routine. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFE94xMXM+XOp70dwoRAhgaAJ4y+4IxdsF+Rn/bwIvV4sFLJxvxWwCePjNW fFFXrkt0wudA/LfW7Wy4nCE= =qhBU -----END PGP SIGNATURE----- From mstuff at read.org.nz Fri Sep 1 09:11:45 2006 From: mstuff at read.org.nz (Morgan Read) Date: Fri, 01 Sep 2006 21:11:45 +1200 Subject: usability: fedora's killer app? Clean-Install Assistant... In-Reply-To: <44F6CF9E.1010507@fedoraproject.org> References: <44F6CE7E.5020509@read.org.nz> <44F6CF9E.1010507@fedoraproject.org> Message-ID: <44F7F951.7010301@read.org.nz> Rahul wrote: > Morgan Read wrote: >> What's the worst thing about operating systems and progress? >> >> Clean-install/Re-install/Upgrade ... > You might be interested in > http://fedoraproject.org/wiki/AnacondaWorkItems#upgrade. > I would love to have a upgrade assistant like what you suggest too. YES! But, I would extend that to /home because, while in a technical sense perhaps /home is considered "non-default non-system information customisation" clearly from a users point of view (usability?...) there is a default - what get set up as the default when a new user is created. AND this is, from the novice desktop users point of view, where most of the progress is apparent from one iteration of fedora to the next. M. (Looks like since I left MacOS8.1 behind Apple have incorporated Clean-Install Assistant in their OS) -- Morgan Read NEW ZEALAND fedora: Freedom Forever! http://fedoraproject.org/wiki/Overview "By choosing not to ship any proprietary or binary drivers, Fedora does differ from other distributions. ..." Quote: Max Spevik http://interviews.slashdot.org/article.pl?sid=06/08/17/177220 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mstuff at read.org.nz Fri Sep 1 11:15:16 2006 From: mstuff at read.org.nz (Morgan Read) Date: Fri, 01 Sep 2006 23:15:16 +1200 Subject: usability: fedora's killer app? Clean-Install Assistant... In-Reply-To: <604aa7910608311147q10abe878i8d570a8c59f414a5@mail.gmail.com> References: <44F6CE7E.5020509@read.org.nz> <604aa7910608311147q10abe878i8d570a8c59f414a5@mail.gmail.com> Message-ID: <44F81644.5050702@read.org.nz> Jeff Spaleta wrote: > On 8/31/06, Morgan Read wrote: >> Of course fedora is somewhat more sophisticated than MacOS 8.1, but the >> principle's the same. Basically, what I have to do at least every >> 6mths is: >> - List my packages > easily done.. and in fact a nightly list of packages is generated by a > cronscript > /var/log/rpmpkgs by the associated cronjob. That's interesting, but not very useful for diff'ing before and after and running yum against - for that something like: $ rpm -qa --qf "%{NAME}\n" | sort -n is necessary. And, then you'd want to add in some information about which packages have been obsoleted and replaced... And then, some information about the implications for the various configs involved... > >> - List all changes to /home/me/ > > changes in /home/ could not be tracked since pretty much everything > down in /home/ is non-default and its not even regarded as system > information. You would need to backup all of /home/, no need to try to > track changes inside /home when all of /home is considered a > customization. See my response to Rahul. But, to be honest, I can't keep a track of what's custom and what's default in the various .gnome .gnome2 .gconf .gconfd .evolution .nautilus etc...; you get the picture - it's a right royal pita ... >> - back up /home/me/ and /etc/ > > backup to where and how? backing up a user's space while outside of > an enterprise network is still a huge problem with no reasonably I usually just move them to /home/mex/ /home/etc/ (guess it's pretty much what's suggested by Rahul at http://fedoraproject.org/wiki/AnacondaWorkItems#upgrade, plus /home/) ... > We need to solve the problem of providing a generally useful and > accessible backup facility that can handle removable media, local I've been using Mondo - but, that's a different context. I don't understand why it's not included somewhere. ... > Easily said... not easily done if there is system configuration syntax > changes which requires hand editting. Didn't we just see this sort of > thing happen in fc5 with the internal changes in apache's modules? I was envisioning something that could diff the two files and offer options about what to do about those diff's, with some contextual info thrown in for good measure ... > rpmpkg log already exists > rpm -V can tell you what configs have been customized > rpm -qf can be used to see if files in /etc/ are unknown to rpm and > thus may need to be backed up. > > writing a simple script to parse these isn't a big deal.... in fact > this is the sort of thing perl is only good for. > > The big gaping hole in the set of technology needed for your wizard is > a comprehensive and accessible backup technology that is easily I think Rhoul has covered that in his link ref'd above? Regards, M. -- Morgan Read NEW ZEALAND fedora: Freedom Forever! http://fedoraproject.org/wiki/Overview "By choosing not to ship any proprietary or binary drivers, Fedora does differ from other distributions. ..." Quote: Max Spevik http://interviews.slashdot.org/article.pl?sid=06/08/17/177220 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bryanlivingston at gmail.com Sat Sep 2 20:43:23 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sat, 2 Sep 2006 14:43:23 -0600 Subject: Modern File Heirarchy Message-ID: Do away with the standard unix directory heirarchy. It's archaic, non-intuitive, non-internationalized and dangerous from an application management perspective. This would be a massive change to the entire system, primarily consisting of creating some standard env variables that point to standard directories. Also a switch to application directories would be done. A linux distribution has been built around this idea and has been successfull at working out the technical details. It's called GoboLinux and you can find out more about it here: http://www.gobolinux.org/?page=at_a_glance They have a piece on common conserns about the idea here: http://www.gobolinux.org/index.php?page=doc/articles/clueless This would take big steps in both usability and internationalization, which are both top goals for Fedora. I'm hoping that the Fedora leadership is serious enough about pushing the state of the technology that they will seriously consider such an idea. It will have to happen eventually in my opinion. This is done on the windows world, and is one aspact that makes windows easier to use and more flexible than Fedora. There are 12 env variables on my win xp system that point to directories for various things. -- Bryan Livingston From mattdm at mattdm.org Sat Sep 2 22:20:47 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Sep 2006 18:20:47 -0400 Subject: Modern File Heirarchy In-Reply-To: References: Message-ID: <20060902222047.GA12498@jadzia.bu.edu> On Sat, Sep 02, 2006 at 02:43:23PM -0600, Bryan Livingston wrote: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. No filesystem hierarchy is intuitive. Therefore, until we've got a solution for that, let's not muck around with the perfectly serviceable one we've got. > This is done on the windows world, and is one aspact that makes > windows easier to use and more flexible than Fedora. There are 12 env Actually, it's one of the things that makes Windows a management and security nightmare. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From bryanlivingston at gmail.com Sun Sep 3 00:28:54 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sat, 2 Sep 2006 18:28:54 -0600 Subject: Modern File Heirarchy In-Reply-To: <20060902222047.GA12498@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: On 9/2/06, Matthew Miller wrote: > On Sat, Sep 02, 2006 at 02:43:23PM -0600, Bryan Livingston wrote: > > Do away with the standard unix directory heirarchy. It's archaic, > > non-intuitive, non-internationalized and dangerous from an application > > management perspective. > > No filesystem hierarchy is intuitive. Therefore, until we've got a solution > for that, let's not muck around with the perfectly serviceable one we've > got. Directories named with plain english words are easier to understand than things like /etc and /usr. Do you not see that? > > This is done on the windows world, and is one aspact that makes > > windows easier to use and more flexible than Fedora. There are 12 env > > Actually, it's one of the things that makes Windows a management and > security nightmare. I don't see how that is. Having the system directory change from c:\winnt to c:\windows never cost me a single bit of grief, while it did allow for side by side installs. I realize that this idea is pretty drastic and don't expect you to like the idea at first glance. All I'm asking is that you give it some serious thought rather than shoot it down out of arrogance. Bryan From mattdm at mattdm.org Sun Sep 3 01:28:49 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 2 Sep 2006 21:28:49 -0400 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: <20060903012849.GA21319@jadzia.bu.edu> On Sat, Sep 02, 2006 at 06:28:54PM -0600, Bryan Livingston wrote: > >No filesystem hierarchy is intuitive. Therefore, until we've got a solution > >for that, let's not muck around with the perfectly serviceable one we've > >got. > Directories named with plain english words are easier to understand > than things like /etc and /usr. Do you not see that? No, they're just more likely to be misleading. Did you read the part of the Gobolinux page you sent a reference to that argues against this very claim? > >> This is done on the windows world, and is one aspact that makes > >> windows easier to use and more flexible than Fedora. There are 12 env > >Actually, it's one of the things that makes Windows a management and > >security nightmare. > I don't see how that is. Having the system directory change from > c:\winnt to c:\windows never cost me a single bit of grief, while it > did allow for side by side installs. But that's just the very beginning of it -- inside that directory, there's a random forest of abstrusely named subdirectories, including a mess of 3rd-party and non-system Microsoft app trees and individual files. Oh, including home directories. Then, there's "Program Files", which acts like a very messy /opt, with a bunch of non-packaged managed junk. Except for C:\Program Files\Common, which is magic. The rest of the filesystem layout is an undefined mess. Windows is such a bad model here that it's not really constructive to even talk about it except as a counterexample. > I realize that this idea is pretty drastic and don't expect you to > like the idea at first glance. All I'm asking is that you give it > some serious thought rather than shoot it down out of arrogance. I'm not. I'm shooting it down out of experience with the well-known arguments. I agree that the traditional hierarchy isn't all that obvious, but it's not all that bad either. The way forward isn't incremental mucking with what things are called, but in rethinking the basic assumptions of the model. (Start with "why a hierarchy?") -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Sun Sep 3 04:30:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 02 Sep 2006 21:30:53 -0700 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: <44FA5A7D.3000304@thecodergeek.com> Bryan Livingston wrote: > Directories named with plain english words are easier to understand > than things like /etc and /usr. Do you not see that? Easier to understand in what way? There's something called the Filesystem Hierarchy Standard [1], which defines explicitly what each directory in a Unix-like system is for. (There is also the hier(7) manual page that contains the same information.) Also, please remember that English is not the only language in use for most GNU/Linux distributions. For example, instead of "/etc" you'd have to account or using "Configuration" (English) or "Configuraci?n" (Spanish) or even things like "Configura??o" (Portuguese). > I don't see how that is. Having the system directory change from > c:\winnt to c:\windows never cost me a single bit of grief, while it > did allow for side by side installs. Concurrent installs of different versions/etc can be done in GNU/Linux as well. Is there an aspect of this that you're referring to that prevents or discourages this? [1] http://www.pathname.com/fhs/ -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Sun Sep 3 04:35:30 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sat, 02 Sep 2006 21:35:30 -0700 Subject: Modern File Heirarchy In-Reply-To: <20060903012849.GA21319@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> Message-ID: <44FA5B92.4040105@thecodergeek.com> Matthew Miller wrote: > (Start with "why a hierarchy?") The human mind, for one, is extremely adept at categorizing and grouping items. By applying that understanding to the functionality of computers and technology in general, we make that technology more readily accessible (not necessarily "easier" per se). -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From bryanlivingston at gmail.com Sun Sep 3 06:18:28 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sun, 3 Sep 2006 00:18:28 -0600 Subject: Modern File Heirarchy In-Reply-To: <44FA5A7D.3000304@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <44FA5A7D.3000304@thecodergeek.com> Message-ID: > Also, please remember that English is not the only language in use for most > GNU/Linux distributions. For example, instead of "/etc" you'd have to account > or using "Configuration" (English) or "Configuraci?n" (Spanish) or even things > like "Configura??o" (Portuguese). Exactly, if the directories were referenced from an environmental variable, localized directories would become possible. From bryanlivingston at gmail.com Sun Sep 3 06:21:55 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sun, 3 Sep 2006 00:21:55 -0600 Subject: Modern File Heirarchy In-Reply-To: <44FA5A7D.3000304@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <44FA5A7D.3000304@thecodergeek.com> Message-ID: > Concurrent installs of different versions/etc can be done in GNU/Linux as well. > Is there an aspect of this that you're referring to that prevents or discourages > this? With Linux I'm only familiar with doing it on separate partitions. In windows at least you can run side by side on a single file system. From bryanlivingston at gmail.com Sun Sep 3 06:24:04 2006 From: bryanlivingston at gmail.com (Bryan Livingston) Date: Sun, 3 Sep 2006 00:24:04 -0600 Subject: Modern File Heirarchy In-Reply-To: <20060903012849.GA21319@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> Message-ID: > I agree that the traditional hierarchy isn't all that obvious, but it's not > all that bad either. The way forward isn't incremental mucking with what > things are called, but in rethinking the basic assumptions of the model. > (Start with "why a hierarchy?") Doing away with the hierarchy reminds me of the way that macs try to sweep the actual file system under the rug and hide it behind a gui. That might be fine for dumb end users but as a power user it totally turns me off. -- Bryan Livingston From mattdm at mattdm.org Sun Sep 3 15:20:05 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 11:20:05 -0400 Subject: Modern File Heirarchy In-Reply-To: <44FA5B92.4040105@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> Message-ID: <20060903152005.GA20923@jadzia.bu.edu> On Sat, Sep 02, 2006 at 09:35:30PM -0700, Peter Gordon wrote: > > (Start with "why a hierarchy?") > > The human mind, for one, is extremely adept at categorizing and grouping > items. By applying that understanding to the functionality of computers > and technology in general, we make that technology more readily accessible > (not necessarily "easier" per se). Sure. Categorizing and grouping is great. But is a tree the best representation? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Sep 3 15:23:17 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 11:23:17 -0400 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> Message-ID: <20060903152317.GB20923@jadzia.bu.edu> On Sun, Sep 03, 2006 at 12:24:04AM -0600, Bryan Livingston wrote: > >I agree that the traditional hierarchy isn't all that obvious, but it's not > >all that bad either. The way forward isn't incremental mucking with what > >things are called, but in rethinking the basic assumptions of the model. > >(Start with "why a hierarchy?") > Doing away with the hierarchy reminds me of the way that macs try to > sweep the actual file system under the rug and hide it behind a gui. > That might be fine for dumb end users but as a power user it totally > turns me off. So, you'd rather paper-over with renamings. *shrug*. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Sep 3 15:25:33 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 11:25:33 -0400 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> <44FA5A7D.3000304@thecodergeek.com> Message-ID: <20060903152533.GC20923@jadzia.bu.edu> On Sun, Sep 03, 2006 at 12:18:28AM -0600, Bryan Livingston wrote: > >Also, please remember that English is not the only language in use for most > >GNU/Linux distributions. For example, instead of "/etc" you'd have to > >account > >or using "Configuration" (English) or "Configuraci?n" (Spanish) or even > >things > >like "Configura??o" (Portuguese). > Exactly, if the directories were referenced from an environmental > variable, localized directories would become possible. Did you read the Gobolinux FAQ entry on this? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Sep 3 15:26:15 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 11:26:15 -0400 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> <44FA5A7D.3000304@thecodergeek.com> Message-ID: <20060903152615.GD20923@jadzia.bu.edu> On Sun, Sep 03, 2006 at 12:21:55AM -0600, Bryan Livingston wrote: > >Concurrent installs of different versions/etc can be done in GNU/Linux as > >well. Is there an aspect of this that you're referring to that prevents > >or discourages this? > With Linux I'm only familiar with doing it on separate partitions. In > windows at least you can run side by side on a single file system. As I said before, that's only because Windows is terrible at handling partitions. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jason at cassiopaea.com Sun Sep 3 16:26:52 2006 From: jason at cassiopaea.com (Jason Knight-Martin) Date: Sun, 03 Sep 2006 18:26:52 +0200 Subject: Modern File Heirarchy In-Reply-To: <20060903152615.GD20923@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <44FA5A7D.3000304@thecodergeek.com> <20060903152615.GD20923@jadzia.bu.edu> Message-ID: <44FB024C.3020100@cassiopaea.com> Matthew Miller wrote: > On Sun, Sep 03, 2006 at 12:21:55AM -0600, Bryan Livingston wrote: > >>> Concurrent installs of different versions/etc can be done in GNU/Linux as >>> well. Is there an aspect of this that you're referring to that prevents >>> or discourages this? >>> >> With Linux I'm only familiar with doing it on separate partitions. In >> windows at least you can run side by side on a single file system. >> > > As I said before, that's only because Windows is terrible at handling > partitions. > > In the end, the hierarchy is arbitrary, you can write any interpretation to cover it up and make it appear different, as we have seen on OSX. Personally, I come from the Linux as a religion corner, unless you can show without doubt that the filesystem is essentially flawed, then you are messing with something sacro-sanct out of self-importance. Of all the things on the dock to work on in the Linux environment, changing the filesystem opens up the least number of possibilities for advancement in concrete usability. /Jason Knight From jspaleta at gmail.com Sun Sep 3 21:32:19 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 3 Sep 2006 13:32:19 -0800 Subject: Modern File Heirarchy In-Reply-To: References: <20060902222047.GA12498@jadzia.bu.edu> Message-ID: <604aa7910609031432g3565e672wf44087e0e8994d4a@mail.gmail.com> On 9/2/06, Bryan Livingston wrote: > I realize that this idea is pretty drastic and don't expect you to > like the idea at first glance. All I'm asking is that you give it > some serious thought rather than shoot it down out of arrogance. Take your earth shattering ideas over to the mailinglists which work on the FHS if you are seriously interested in working with people to change things as fundamental as the filesystem directory structure naming. Remember that part of Fedora's mission is to work WITH upstream developers as much as possible. If you and the gobolinux people really think this is the wave of the future, put your best foot forward and engage the people who control the FHS document. I would however caution you to use far less provocative and emotional a writing style. And do your best to avoid such classically ironic comments such as the above arrogant insinuation concerning the arrogance of others. I personally think it would be quite...arrogant... for the Fedora leadership to make such a fundamental change on the strength of your passionate, if there hasn't been a discussion with the people driving the established filesystem standardization process about your idea. For reference, here is the page of interest concerning FHS discussions: http://www.pathname.com/fhs/ -jef"english-centric views are so narrow-minded, so 20th century, so decedent western society...if we are going to make a drastic change.. lets rename the filesystem in chinese"spaleta From peter at thecodergeek.com Sun Sep 3 22:03:53 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 03 Sep 2006 15:03:53 -0700 Subject: Modern File Heirarchy In-Reply-To: <20060903152005.GA20923@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> Message-ID: <44FB5149.7020703@thecodergeek.com> Matthew Miller wrote: > Sure. Categorizing and grouping is great. But is a tree the best > representation? In something like this, yes. The hierarchy continues subdividing the filesystem into distinct areas, similar to how one might organize their home directory with a folder for music, one for documents, one for videos, one for pictures, etc. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From david at lovesunix.net Sun Sep 3 22:29:33 2006 From: david at lovesunix.net (David Nielsen) Date: Mon, 04 Sep 2006 00:29:33 +0200 Subject: Modern File Heirarchy In-Reply-To: <44FB5149.7020703@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> Message-ID: <1157322573.3026.34.camel@price> s?n, 03 09 2006 kl. 15:03 -0700, skrev Peter Gordon: > Matthew Miller wrote: > > Sure. Categorizing and grouping is great. But is a tree the best > > representation? > > In something like this, yes. The hierarchy continues subdividing the > filesystem into distinct areas, similar to how one might organize their > home directory with a folder for music, one for documents, one for videos, > one for pictures, etc. This just SCREAMS translation hell to me, it's bad enough that f-spot and banshee both by default creates and uses english directories in my homedir. f-spot being the biggest offender since you can't change the directory name. Now if we are talking about some kind of vFolder it would be entirely possible to hide the nastiness that is FHS (and by deity I hate the FHS) and we could solve translation issues as well I think since a vFolder could be created in runtime and wouldn't rely on physical presence on the harddrive. I imagine Beagle or Tracker would be our friends in this area. If a proposal to fix this once and for all is to be made, let's addresse all the issues and do the work upstream where possible. Simply renaming the directories will be not solve every issue the FHS has nor will it provide the extensions we need on the desktop to make assumptions as to placement of files by type. The only sane thing to do is to create a vFolder on the fly on a per session basis using search results from something like Beagle. We could thus assume putting photos in ~/.photos and having a generated search folder for photos localized (encompassing .photos and everywhere else in ~), in my case that would be ~/Billeder (da_DK.UTF-8) for use in Nautilus and as a bonus it would be visible in the terminal as well if we did it correctly at least. - David Nielsen From peter at thecodergeek.com Sun Sep 3 23:09:00 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 03 Sep 2006 16:09:00 -0700 Subject: Modern File Heirarchy In-Reply-To: <1157322573.3026.34.camel@price> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <1157322573.3026.34.camel@price> Message-ID: <44FB608C.6080204@thecodergeek.com> David Nielsen wrote: > s?n, 03 09 2006 kl. 15:03 -0700, skrev Peter Gordon: >> In something like this, yes. The hierarchy continues subdividing the >> filesystem into distinct areas, similar to how one might organize their >> home directory with a folder for music, one for documents, one for videos, >> one for pictures, etc. > This just SCREAMS translation hell to me, it's bad enough that f-spot > and banshee both by default creates and uses english directories in my > homedir. f-spot being the biggest offender since you can't change the > directory name. Exactly why I like, for one, like the idea of having standardized names for the directories: /usr, /lib, /srv, /var, /var/log, etc. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Sun Sep 3 23:12:46 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 03 Sep 2006 16:12:46 -0700 Subject: Modern File Heirarchy In-Reply-To: <44FB608C.6080204@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <1157322573.3026.34.camel@price> <44FB608C.6080204@thecodergeek.com> Message-ID: <44FB616E.1080309@thecodergeek.com> Peter Gordon wrote: > Exactly why I like, for one, like the idea of having standardized names for the > directories: /usr, /lib, /srv, /var, /var/log, etc. :) That should be "... why I, for one, like ...". Pardon my apparent lack of caffeine. :) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From mattdm at mattdm.org Sun Sep 3 23:32:24 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 19:32:24 -0400 Subject: Modern File Heirarchy In-Reply-To: <44FB608C.6080204@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <1157322573.3026.34.camel@price> <44FB608C.6080204@thecodergeek.com> Message-ID: <20060903233224.GA2769@jadzia.bu.edu> On Sun, Sep 03, 2006 at 04:09:00PM -0700, Peter Gordon wrote: > >> In something like this, yes. The hierarchy continues subdividing the > >> filesystem into distinct areas, similar to how one might organize their > >> home directory with a folder for music, one for documents, one for > >> videos, one for pictures, etc. [...] > Exactly why I like, for one, like the idea of having standardized names > for the directories: /usr, /lib, /srv, /var, /var/log, etc. :) Which one of those is for the music videos? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Sun Sep 3 23:33:12 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Sun, 3 Sep 2006 19:33:12 -0400 Subject: Modern File Heirarchy In-Reply-To: <44FB5149.7020703@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> Message-ID: <20060903233312.GB2769@jadzia.bu.edu> On Sun, Sep 03, 2006 at 03:03:53PM -0700, Peter Gordon wrote: > > Sure. Categorizing and grouping is great. But is a tree the best > > representation? > In something like this, yes. The hierarchy continues subdividing the > filesystem into distinct areas, similar to how one might organize their > home directory with a folder for music, one for documents, one for videos, > one for pictures, etc. What you've described here is a flat list, not a tree. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From peter at thecodergeek.com Sun Sep 3 23:46:25 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 03 Sep 2006 16:46:25 -0700 Subject: Modern File Heirarchy In-Reply-To: <20060903233224.GA2769@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <1157322573.3026.34.camel@price> <44FB608C.6080204@thecodergeek.com> <20060903233224.GA2769@jadzia.bu.edu> Message-ID: <44FB6951.5060106@thecodergeek.com> Matthew Miller wrote: > On Sun, Sep 03, 2006 at 04:09:00PM -0700, Peter Gordon wrote: >>>> In something like this, yes. The hierarchy continues subdividing the >>>> filesystem into distinct areas, similar to how one might organize their >>>> home directory with a folder for music, one for documents, one for >>>> videos, one for pictures, etc. > [...] >> Exactly why I like, for one, like the idea of having standardized names >> for the directories: /usr, /lib, /srv, /var, /var/log, etc. :) > Which one of those is for the music videos? Those I mentioned are system-level directories. How you store things on your own depends on how you like to organize your system. I tend to keep large things like videos and ISO images on a secondary hard disk (/mnt/Storage), while smaller things like documents and music files I keep in my home directory (~/Music, ~/Documents, ~/Documents/Schoolwork, ~/Photos, ~/Wallpapers, etc.) -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From peter at thecodergeek.com Sun Sep 3 23:53:54 2006 From: peter at thecodergeek.com (Peter Gordon) Date: Sun, 03 Sep 2006 16:53:54 -0700 Subject: Modern File Heirarchy In-Reply-To: <20060903233312.GB2769@jadzia.bu.edu> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <20060903233312.GB2769@jadzia.bu.edu> Message-ID: <44FB6B12.1070905@thecodergeek.com> Matthew Miller wrote: > On Sun, Sep 03, 2006 at 03:03:53PM -0700, Peter Gordon wrote: >>> Sure. Categorizing and grouping is great. But is a tree the best >>> representation? >> In something like this, yes. The hierarchy continues subdividing the >> filesystem into distinct areas, similar to how one might organize their >> home directory with a folder for music, one for documents, one for videos, >> one for pictures, etc. > > What you've described here is a flat list, not a tree. Thanks for pointing this out. I intended to exemplify something like what I have in my home directory: In ~/Music, I have directories for each artist I listen to, then within those I have directories for each album by that artist, then within _those_ I place the audio tracks. So, for instance, my copy of Arch Enemy's "Wages of Sin" album is stored as FLACs in "~/Music/Arch Enemy/Wages of Sin" As another example, my ~/Documents directory contains directories for Work, Schoolwork, and one entitled "Random Musings." Stuff I do for my job is placed in ~/Documents/Work, while the "Random Musings" subdirectory is where I store various poetry and/or articles I'm writing. Within the Schoolwork subdirectory, I have one subdirectory for each class, so if I had something for my physics class this semester, I'd store it in a directory path of "~/Documents/Schoolwork/Phys 221" for example. Hope that helps. -- Peter Gordon (codergeek42) GnuPG Public Key ID: 0xFFC19479 / Fingerprint: DD68 A414 56BD 6368 D957 9666 4268 CB7A FFC1 9479 My Blog: http://thecodergeek.com/blog/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Mon Sep 4 06:45:58 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 04 Sep 2006 08:45:58 +0200 Subject: Modern File Heirarchy In-Reply-To: <44FB6B12.1070905@thecodergeek.com> References: <20060902222047.GA12498@jadzia.bu.edu> <20060903012849.GA21319@jadzia.bu.edu> <44FA5B92.4040105@thecodergeek.com> <20060903152005.GA20923@jadzia.bu.edu> <44FB5149.7020703@thecodergeek.com> <20060903233312.GB2769@jadzia.bu.edu> <44FB6B12.1070905@thecodergeek.com> Message-ID: <1157352358.7430.2.camel@rousalka.dyndns.org> You're all writing about $HOME organisation, which is orthogonal to the FHS since the current FHS does not specify it. And yes cleaning up the $HOME mess (hidden dirs/files with random conventions) would be nice, but it's a major work and requires at least Gnome+KDE buy-in (then years of hunting offending apps) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jason at cassiopaea.com Mon Sep 4 11:19:13 2006 From: jason at cassiopaea.com (Jason Knight-Martin) Date: Mon, 04 Sep 2006 13:19:13 +0200 Subject: Modern File Heirarchy In-Reply-To: <604aa7910609031432g3565e672wf44087e0e8994d4a@mail.gmail.com> References: <20060902222047.GA12498@jadzia.bu.edu> <604aa7910609031432g3565e672wf44087e0e8994d4a@mail.gmail.com> Message-ID: <44FC0BB1.6030907@cassiopaea.com> Jeff Spaleta wrote: > On 9/2/06, Bryan Livingston wrote: >> I realize that this idea is pretty drastic and don't expect you to >> like the idea at first glance. All I'm asking is that you give it >> some serious thought rather than shoot it down out of arrogance. > > Take your earth shattering ideas over to the mailinglists which work > on the FHS if you are seriously interested in working with people to > change things as fundamental as the filesystem directory structure > naming. Remember that part of Fedora's mission is to work WITH > upstream developers as much as possible. If you and the gobolinux > people really think this is the wave of the future, put your best foot > forward and engage the people who control the FHS document. I would > however caution you to use far less provocative and emotional a > writing style. And do your best to avoid such classically ironic > comments such as the above arrogant insinuation concerning the > arrogance of others. I personally think it would be > quite...arrogant... for the Fedora leadership to make such a > fundamental change on the strength of your passionate, if there hasn't > been a discussion with the people driving the established filesystem > standardization process about your idea. Here here, I for one and getting tired of this in my inbox. > > For reference, here is the page of interest concerning FHS discussions: > http://www.pathname.com/fhs/ > > -jef"english-centric views are so narrow-minded, so 20th century, so > decedent western society...if we are going to make a drastic change.. > lets rename the filesystem in chinese"spaleta I agree with this :) -jason"Computer systems should be designed in such a way as to be incomprehensible to the newcomer and elite hacker alike, computers must be an equalizer in so much as we are all equally ignorant, an esoteric quest for understanding if you will. Making things easy is the Windows way at the cost of control, making things beautiful is the Apple way at the cost of freedom, making things functional is the Linux way at the cost of immediate comprehension."knight From rdieter at math.unl.edu Tue Sep 5 12:45:51 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 05 Sep 2006 07:45:51 -0500 Subject: Modern File Heirarchy References: <20060902222047.GA12498@jadzia.bu.edu> <604aa7910609031432g3565e672wf44087e0e8994d4a@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 9/2/06, Bryan Livingston wrote: >> I realize that this idea is pretty drastic and don't expect you to >> like the idea at first glance. > Take your earth shattering ideas over to the mailinglists which work > on the FHS if you are seriously interested in working with people to > change things as fundamental as the filesystem directory structure > naming. Remember that part of Fedora's mission is to work WITH > upstream developers as much as possible. > ... +1 (Thanks Jeff, couldn't have said it better myself). -- Rex From mstuff at read.org.nz Wed Sep 6 10:32:37 2006 From: mstuff at read.org.nz (Morgan Read) Date: Wed, 06 Sep 2006 22:32:37 +1200 Subject: ALT - Modern File Heirarchy In-Reply-To: References: Message-ID: <44FEA3C5.9020408@read.org.nz> There is an alternative to dumbing down the file system, that's wisen-up the user. From a novice point of view I suggested something like this in this bug: http://bugzilla.gnome.org/show_bug.cgi?id=168642 All the information's available, all the tools are available: 'tool-tips'; Notes tab in Gnomes Properties dialogue. Just populate the Notes with useful educational information about the file system which by default displays as a 'tool-tip' over various elements of the file system (when it becomes annoying and redundant comment the Notes out, or some such, so they go away). M. Bryan Livingston wrote: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. > > This would be a massive change to the entire system, primarily > consisting of creating some standard env variables that point to > standard directories. Also a switch to application directories would > be done. > > A linux distribution has been built around this idea and has been > successfull at working out the technical details. It's called > GoboLinux and you can find out more about it here: > http://www.gobolinux.org/?page=at_a_glance They have a piece on > common conserns about the idea here: > http://www.gobolinux.org/index.php?page=doc/articles/clueless > > This would take big steps in both usability and internationalization, > which are both top goals for Fedora. I'm hoping that the Fedora > leadership is serious enough about pushing the state of the technology > that they will seriously consider such an idea. It will have to > happen eventually in my opinion. > > This is done on the windows world, and is one aspact that makes > windows easier to use and more flexible than Fedora. There are 12 env > variables on my win xp system that point to directories for various > things. > -- Morgan Read NEW ZEALAND fedora: Freedom Forever! http://fedoraproject.org/wiki/Overview "By choosing not to ship any proprietary or binary drivers, Fedora does differ from other distributions. ..." Quote: Max Spevik http://interviews.slashdot.org/article.pl?sid=06/08/17/177220 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: OpenPGP digital signature URL: From roguexz at gmail.com Wed Sep 6 17:05:42 2006 From: roguexz at gmail.com (Rogue) Date: Wed, 06 Sep 2006 22:35:42 +0530 Subject: Themes & Icons related Message-ID: <44FEFFE6.2040202@gmail.com> An HTML attachment was scrubbed... URL: From notting at redhat.com Wed Sep 6 20:40:02 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 6 Sep 2006 16:40:02 -0400 Subject: [fab] Modern File Heirarchy In-Reply-To: References: Message-ID: <20060906204002.GA3243@nostromo.devel.redhat.com> Bryan Livingston (bryanlivingston at gmail.com) said: > Do away with the standard unix directory heirarchy. It's archaic, > non-intuitive, non-internationalized and dangerous from an application > management perspective. OK, why is this *AT ALL* appropriate for the board - what's your purpose here? If you can't convince the project itself, why are you bringing this to an administrative entity? Bill From sundaram at fedoraproject.org Wed Sep 6 21:38:04 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 07 Sep 2006 03:08:04 +0530 Subject: [fab] Modern File Heirarchy In-Reply-To: <20060906204002.GA3243@nostromo.devel.redhat.com> References: <20060906204002.GA3243@nostromo.devel.redhat.com> Message-ID: <44FF3FBC.1040406@fedoraproject.org> Bill Nottingham wrote: > Bryan Livingston (bryanlivingston at gmail.com) said: >> Do away with the standard unix directory heirarchy. It's archaic, >> non-intuitive, non-internationalized and dangerous from an application >> management perspective. > > OK, why is this *AT ALL* appropriate for the board - what's your > purpose here? > > If you can't convince the project itself, why are you bringing > this to an administrative entity? > > Bill I think people quite often confuse Fedora Project Board to be a technical decisions team (which I think should be formed by merging FESCo and people from Fedora Core) rather than a administrative team which is partially our fault since we dont have any documents explaining our governance mode, policy and relationship of different teams such as the board and the steering committees. I will get to doing that soon. Rahul From pkukums at ieee.org Wed Sep 6 23:10:05 2006 From: pkukums at ieee.org (Peter Kukums) Date: Thu, 07 Sep 2006 09:10:05 +1000 Subject: Modern File Hierarchy Message-ID: <1157584205.2893.7.camel@kookey.com> Just my two cents worth. I think more time should be spent on bits that don't work not bits that do. For example, the package update process. I installed Fedora Core 5 on a new system and I was impressed with how well it worked without much intervention on my part. But yesterday I performed an update of all my installed packages and now I can no longer print to any of my printers (CUPS was updated). How can beginners possibly cope with something like this?? As part of desktop usability they would expect what was once working to keep working!! The update process should be more transparent. And as a beginner I can also see no easy way of rolling back to a previous working version either! From sundaram at fedoraproject.org Thu Sep 7 00:00:53 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 07 Sep 2006 05:30:53 +0530 Subject: Modern File Hierarchy In-Reply-To: <1157584205.2893.7.camel@kookey.com> References: <1157584205.2893.7.camel@kookey.com> Message-ID: <44FF6135.40306@fedoraproject.org> Peter Kukums wrote: > Just my two cents worth. > > I think more time should be spent on bits that don't work not bits that > do. > > For example, the package update process. I installed Fedora Core 5 on a > new system and I was impressed with how well it worked without much > intervention on my part. > > But yesterday I performed an update of all my installed packages and now > I can no longer print to any of my printers (CUPS was updated). How can > beginners possibly cope with something like this?? Seems unrelated to file hierarchy in any manner. Have you filed a bug report on this? As part of desktop > usability they would expect what was once working to keep working!! Thats not desktop usability. Thats general QA for the whole distribution. The > update process should be more transparent. And as a beginner I can also > see no easy way of rolling back to a previous working version either! > Yum recently got a downgrade plugin. See fedora-devel list. Rahul From nicu_fedora at nicubunu.ro Thu Sep 7 05:23:00 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 07 Sep 2006 08:23:00 +0300 Subject: Themes & Icons related In-Reply-To: <44FEFFE6.2040202@gmail.com> References: <44FEFFE6.2040202@gmail.com> Message-ID: <44FFACB4.2010200@nicubunu.ro> Rogue wrote: > I tend to switch my icons and themes to have a glossy look or something > else depending on my mood. Both on my desktop as well as within firefox > and thunderbird. Now for icons within GNOME, i can always pick up icons > from gnome-looks or some such site. But the biggest sore point about > something like that is that i need to keep checking every now and then > on the site to see if there is a newer version of the same theme. But in > the case of my browser, when i check for extensions / themes, the update > procedure is rather simple. > > Now I do understand that it is not a good option that all the theme > writers be asked to publish rpms and maintain a repository. I am > considering that may be we need a simpler update/publish mechanism which > a theme write would be able to build / publish easily. Atleast if we can > get support from the sites themselves to provide such publishings, it > would be great. So the next time I do an update, I am informed about the > various theme updates and get the latest details without having to do a > lot of running around. > > Event if we were to build these themes as rpms, so as to have the least > possible impact to the deployment process, it would be great if > repository information could be provided at some place. I think in your case the best solution would be to have some theme packaged in Fedora Extras, this way those will be packaged as rpm and you will be informed about available updates via puplet. So you may want to ask on the Extras list if people are interested in packaging there GNOME themes. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From duffy at redhat.com Thu Sep 7 13:59:45 2006 From: duffy at redhat.com (=?ISO-8859-1?Q?M=E1ir=EDn_Duffy?=) Date: Thu, 07 Sep 2006 09:59:45 -0400 Subject: Themes & Icons related In-Reply-To: <44FFACB4.2010200@nicubunu.ro> References: <44FEFFE6.2040202@gmail.com> <44FFACB4.2010200@nicubunu.ro> Message-ID: <450025D1.4010506@redhat.com> Hi Nicu, Nicu Buculei wrote: > Rogue wrote: >> Event if we were to build these themes as rpms, so as to have the >> least possible impact to the deployment process, it would be great if >> repository information could be provided at some place. > > I think in your case the best solution would be to have some theme > packaged in Fedora Extras, this way those will be packaged as rpm and > you will be informed about available updates via puplet. > So you may want to ask on the Extras list if people are interested in > packaging there GNOME themes. At one point I was looking at the fdo create project - is something like this the goal of create? ~m From nicu_fedora at nicubunu.ro Thu Sep 7 14:10:50 2006 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 07 Sep 2006 17:10:50 +0300 Subject: Themes & Icons related In-Reply-To: <450025D1.4010506@redhat.com> References: <44FEFFE6.2040202@gmail.com> <44FFACB4.2010200@nicubunu.ro> <450025D1.4010506@redhat.com> Message-ID: <4500286A.2050801@nicubunu.ro> M?ir?n Duffy wrote: > Nicu Buculei wrote: >> >> I think in your case the best solution would be to have some theme >> packaged in Fedora Extras, this way those will be packaged as rpm and >> you will be informed about available updates via puplet. >> So you may want to ask on the Extras list if people are interested in >> packaging there GNOME themes. > > At one point I was looking at the fdo create project - is something like > this the goal of create? The main idea when "create" was started was to provide collaboration between *applications*, but it is not very active or very well defined so there is place for it to evolve in various directions if someone takes an initiative. -- nicu Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From roguexz at gmail.com Sat Sep 9 17:31:55 2006 From: roguexz at gmail.com (Rogue) Date: Sat, 09 Sep 2006 23:01:55 +0530 Subject: Themes Related: Ability to select a icon size from those provided by the theme Message-ID: <4502FA8B.60301@gmail.com> An HTML attachment was scrubbed... URL: From chitlesh at fedoraproject.org Sun Sep 10 11:57:19 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Sun, 10 Sep 2006 13:57:19 +0200 Subject: Kadischi GUI : usability Message-ID: <13dbfe4f0609100457m48187775s3ce96a319d0e074b@mail.gmail.com> Hello there, I'm here to seek advice and suggestions on Kadischi's GUI. I have been directed by many of you to this list from IRC. After several GUI ideas I had, finally I chose one. When kadischi is launched from gnome/kde menu, http://www.flickr.com/photo_zoom.gne?id=239174347&size=o When the "next" button is clicked, General tab: http://www.flickr.com/photo_zoom.gne?id=239174348&size=o Advanced Features tab: http://www.flickr.com/photo_zoom.gne?id=239174350&size=o Rebranding tab: http://www.flickr.com/photo_zoom.gne?id=239174351&size=o UserAccounts tab: http://www.flickr.com/photo_zoom.gne?id=239174352&size=o Unconfigured tab: http://www.flickr.com/photo_zoom.gne?id=239174355&size=o When the "Build image" button is clicked, Output tab: http://www.flickr.com/photo_zoom.gne?id=239175327&size=o The codes behind the different features hasn't yet been written, but soon will :). Regards, Chitlesh Goorah -- http://clunixchit.blogspot.com From david at fubar.dk Wed Sep 13 21:58:51 2006 From: david at fubar.dk (David Zeuthen) Date: Wed, 13 Sep 2006 17:58:51 -0400 Subject: Kadischi GUI : usability In-Reply-To: <13dbfe4f0609100457m48187775s3ce96a319d0e074b@mail.gmail.com> References: <13dbfe4f0609100457m48187775s3ce96a319d0e074b@mail.gmail.com> Message-ID: <1158184732.2620.23.camel@daxter.boston.redhat.com> On Sun, 2006-09-10 at 13:57 +0200, Chitlesh GOORAH wrote: > Hello there, > > I'm here to seek advice and suggestions on Kadischi's GUI. I have been > directed by many of you to this list from IRC. > > After several GUI ideas I had, finally I chose one. Maybe one question to ask is whether it makes sense to have a GUI at all? I mean, looking at your proposed UI, even though I suppose you tried hard, it contains all sort of information that only experienced Fedora users truly understands. And these are very likely to be capable of editing configuration or scripts. I guess, I'm saying that it's a bit like e.g. system-config-httpd or system-config-bind - a pretty UI that doesn't really do everything you want. And if you can make it do the things you want, it's usually much easier just to edit the files in shell. For example, what would happen if I'd want to configure other bits than the ones exposed in the UI? What if I want to make e.g. NetworkManager default? I'd say, just let users edit a script - that will give them much more freedom, to e.g. configure the system the way they want it. This is just what I think, however. HTH, David From andrewz at springsrescuemission.org Sun Sep 17 16:51:53 2006 From: andrewz at springsrescuemission.org (Andrew Ziem) Date: Sun, 17 Sep 2006 10:51:53 -0600 (MDT) Subject: Usability: SUSE, AD, and caching authentication Message-ID: <14913.63.247.196.146.1158511913.squirrel@narnia.dnsalias.com> Here's two articles about how Novell is integrating with Active Directory. From the looks of it, it's simple, quick, and intuitive to: * Authenticate against Active Directory * Create home directories on login * Cache authentication (for laptops, for example) * Get a Kerberos ticket for passwordless ssh http://www.whiprush.org/2006/09/on_active_direc.html http://reverendted.wordpress.com/2006/09/12/linux-goes-mad/ Andrew From chitlesh at fedoraproject.org Tue Sep 19 14:19:12 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Tue, 19 Sep 2006 16:19:12 +0200 Subject: Kadischi GUI : usability In-Reply-To: <1158184732.2620.23.camel@daxter.boston.redhat.com> References: <13dbfe4f0609100457m48187775s3ce96a319d0e074b@mail.gmail.com> <1158184732.2620.23.camel@daxter.boston.redhat.com> Message-ID: <13dbfe4f0609190719p226795a5odede1436dd8f13ee@mail.gmail.com> On 9/13/06, David Zeuthen wrote: > Maybe one question to ask is whether it makes sense to have a GUI at > all? I mean, looking at your proposed UI, even though I suppose you > tried hard, it contains all sort of information that only experienced > Fedora users truly understands. And these are very likely to be capable > of editing configuration or scripts. Actually there is a meaning behind it, as you may have noticed behind kadischi there is only JasperHartline and I. I'm trying to make a GUI with simple features at first just to gain attention and attract more contributors and testers of different archs. Recently I've posted a Call for testing under 64 bit hardware but haven't got many volunteers, so perhaps a gui might be user friendly. > I guess, I'm saying that it's a bit like e.g. system-config-httpd or > system-config-bind - a pretty UI that doesn't really do everything you > want. And if you can make it do the things you want, it's usually much > easier just to edit the files in shell. > For example, what would happen if I'd want to configure other bits than > the ones exposed in the UI? What if I want to make e.g. NetworkManager > default? I'd say, just let users edit a script - that will give them > much more freedom, to e.g. configure the system the way they want it. > > This is just what I think, however. Indeed, at some point we can't satisfy everyone, but however if someone wants to add such feature as your example, we would be happy to perhaps include it. The more we get feedback the more it will make things behind kadischi moving. Chitlesh -- http://clunixchit.blogspot.com From davidz at redhat.com Wed Sep 20 05:51:28 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 01:51:28 -0400 Subject: pilgrim livecd work Message-ID: <1158731488.26429.83.camel@zelda.fubar.dk> Hey, I've spend a little bit of time adapting the OLPC build system to be able to spit out Fedora livecd's. First some background on what we do in OLPC o OLPC is an OS built on Core but also includes bits from Extras and a dedicated OLPC repository o Rather than using an installer, we deliver the OS in two ways - for USB sticks we provide an image that can be copied onto the whole disk. This image includes a partition table, boot loader and so forth. This image is also used for qemu. - For installation to the OLPC hardware, we provide a JFFS2 file system image that can be put on the flash using nandwrite from mtd-utils o The build system must be easy for downstream to use for creating a derived build of the upstream OLPC distribution. The thinking here is that OLPC customers (which are governments, countries) are able to very easily tweak the package selection, provide alternative packages and change how the system is configured. o (for more info on OLPC development, see http://dev.laptop.org ) As such, the goals are pretty similar to Live CD: Assemble an OS and put it on bootable media. So I spent a few days a few weekends ago to do exactly that; the how's, why's etc. are here http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob_plain;h=aa64cfda24576f3cb81b2ab99b2aae0fb0a2b8ae;f=README.fedora Specifically, I've made it a goal to make live cd's built with this infrastructure possible to install to hard disks such as to provide a nice user experience: you download the livecd and if you like it, you simply press the "Install" icon on the desktop and the OS is installed in a matter of minutes. No need to go through anaconda here. The README.fedora file linked to above contains some pretty specific information of what we need here. With some hard work perhaps we can make this happen for FC7. Another important goal is that it should be easy to create derived CD's. So if you are into the whole Java and Fedora things, maybe you want to easily create a Fedora Eclipse livecd. You know, to show off to your friends. I've included an example here, fedora-eclipse http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=e79cc0e412502104061fa0dd6ccd4e52c32e9c46;hb=5286c7a59d5237c337c9dff4c5ab62832e9ae1c3;f=streams.d/fedora-eclipse.stream note how fedora-eclipse is derived from fedora-gnome http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=f709bc90d9f81e01f1f11d6cc489565c02dea29a;hb=5286c7a59d5237c337c9dff4c5ab62832e9ae1c3;f=streams.d/fedora-gnome.stream which in turn is derived from fedora-base http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=5d9cb98f8d228d2c4b92daabfe615a880c695115;hb=5286c7a59d5237c337c9dff4c5ab62832e9ae1c3;f=streams.d/fedora-base.stream and also that fedora-desktop http://gitweb.freedesktop.org/?p=users/david/pilgrim.git;a=blob;h=8eac448f7733b5857fb6e8c4275bb87d4197b1fe;hb=5286c7a59d5237c337c9dff4c5ab62832e9ae1c3;f=streams.d/fedora-desktop.stream is derived from fedora-base. Ie. we have fedora-base | fedora-gnome | +------------+------------+ | | fedora-eclipse fedora-desktop There is nothing to prevent us from having fedora-base | +---------------------------------+------------+------... | | fedora-gnome fedora-kde | | +------------+------------+----------------+---... .... | | | fedora-eclipse fedora-desktop fedora-music in the future. For example, it's not far fetched, I think, to have people from the tools group in Red Hat maintain the fedora-eclipse live cd bits (in fact, I'm not even sure if that image builds any more, it did some weeks ago. But y'all get the point, yes?) The very nice thing is that downstream, for example fedora-eclipse and fedora-eclipse-kde, would benefit from general improvements in fedora-gnome and fedora-kde. The barrier to entry is pretty low, just look at the simplicity of of the current fedora-eclipse and fedora-desktop stream definition files. Anyway, enough talk, it's getting late and I'm too old to miss sleep these days :-) - Here's a screenshot of the fedora-desktop livecd http://people.freedesktop.org/~david/fedora-desktop-livecd-20060920.png and here is an ISO, weighing 618MB, of fedora-desktop http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-development-build-2-20060919_2225-livecd.iso Have fun, David From davidz at redhat.com Wed Sep 20 15:09:28 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 11:09:28 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <4510F64E.4070207@adelphia.net> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> Message-ID: <1158764968.2518.19.camel@zelda.fubar.dk> (adding back fedora-desktop-list as that Cc: field mysteriously vanished.) On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote: > You really should use the stock Fedora Core utilities however. > If you are making an installer to system from LiveCD, why not use Anaconda? I'd rather ask; Why use anaconda? At the end of the day, installation is a pretty basic task - yum install what you want - write out some configuration files - perform other post-installation configuration. So, you know, I'd hate to replace < 100 lines of code by depending on anaconda, which, I might add, is designed to do far more than the relatively straightforward task of doing live cd's. I'm not even sure it makes sense to carry around code in anaconda to facilitate live cd installs but I'll leave that judgement call to the Anaconda developers. FWIW, yum works perfectly fine and one goal of the pilgrim effort is to make the process as robust as possible as well as being able to run on host OS'es that are not super current. For example, the image I linked to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on it). There's also an historical angle here - pilgrim is the successor to the now defunt olpc-image tools. Anaconda simply didn't allow to be used in this way. > If OLPC is a "derived" from Redhat or Fedora Core distribution, I really > do not see how this pertains to this list. I think Rahul answered this already. I'll also note that this is not a kadishchi specific list (or at least that's my impression) and several people have asked me to specifically post my work here. > On another note, what functionality does this LiveCD stuff you mention > provide over Fedora Core's Kadischi? > If you are unfamiliar with Kadischi, you can find it here: > http://fedoraproject.org/wiki/Kadischi > Available via CVS. I think there are some key differences - specifically designed to be able to install the livecd payload on your hard disk. I've read through the archives of this list and seen objections from Jeremy and others about the feasibility of changing Kadischi to facilitate this. Pretty sure there are few objections to the approach I've taken with pilgrim but I'll leave Jeremy to comment. - designed specifically with downstream consumers in mind, e.g. it must be extremely simple to put together an Fedora Eclipse, Fedora Music, Fedora Livna Desktop, whatever live cd. This is what I tried to describe in my original mail. - r/w root so the OS actually works like it's supposed to (with the live cd ISO that I linked to you can easy yum install what you want or perhaps even use pirut) - Use selinux - ok, so I ran into some issues with enabling this (see the README.fedora file) so it's disabled in the ISO I linked to. However, if your build environment matches the target environment this works nicely. I'll be working on fixing this, certainly OLPC needs this feature anyway. - the codebase pilgrim is based on have been used successfully to build OLPC images for many months now. Pilgrim have now replaced this and is a critical component of the OLPC release infrastructure. As such, I and others are committed to maintaining pilgrim for at least this task. So these are the key differences I think. You probably know how it is with software development. People will use your software in unforeseen ways. As such, as software developers we tend to make our software prepared to do this. I just happened to identify a huge overlap between what we're doing in OLPC and what a nice livecd infrastructure should look like. So I spent a day or two making pilgrim doing just this. Hope this clarifies. David From sundaram at fedoraproject.org Wed Sep 20 15:13:55 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 20:43:55 +0530 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158764968.2518.19.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> Message-ID: <45115AB3.6060704@fedoraproject.org> David Zeuthen wrote: > (adding back fedora-desktop-list as that Cc: field mysteriously > vanished.) > > On Wed, 2006-09-20 at 03:05 -0500, Jasper Hartline wrote: >> You really should use the stock Fedora Core utilities however. >> If you are making an installer to system from LiveCD, why not use Anaconda? > > I'd rather ask; Why use anaconda? At the end of the day, installation is > a pretty basic task > > - yum install what you want > - write out some configuration files > - perform other post-installation configuration. > > So, you know, I'd hate to replace < 100 lines of code by depending on > anaconda, which, I might add, is designed to do far more than the > relatively straightforward task of doing live cd's. I'm not even sure it > makes sense to carry around code in anaconda to facilitate live cd > installs but I'll leave that judgement call to the Anaconda developers. > > FWIW, yum works perfectly fine and one goal of the pilgrim effort is to > make the process as robust as possible as well as being able to run on > host OS'es that are not super current. For example, the image I linked > to are built on an x86_64 RHEL4 box (though I had to put yum 2.9.* on > it). > > There's also an historical angle here - pilgrim is the successor to the > now defunt olpc-image tools. Anaconda simply didn't allow to be used in > this way. David, How do you plan on performing upgrades when the live cd gets a install to hard disk feature? Rahul From gdk at redhat.com Wed Sep 20 15:29:29 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 20 Sep 2006 11:29:29 -0400 (EDT) Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158764968.2518.19.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> Message-ID: On Wed, 20 Sep 2006, David Zeuthen wrote: > > If OLPC is a "derived" from Redhat or Fedora Core distribution, I really > > do not see how this pertains to this list. > > I think Rahul answered this already. I'll also note that this is not a > kadishchi specific list (or at least that's my impression) and several > people have asked me to specifically post my work here. Yes. In fact, I hounded David relentlessly for a couple of weeks to publicize his work here, because I think it's excellent. It's natural to be skeptical of new code, but bear these facts in mind: 1. PRIORITY. Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a large superset of Kadischi's. Anaconda also has significant *business* pressures on its roadmap. Kadischi patches are, therefore, low priority for Anaconda developers. Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD is the same. 2. INSTALL FUNCTIONALITY. If there's one place where Ubuntu has an *actual* lead on us, it's in their ability to install a Live CD directly to a system. From what I've seen, we're closer to closing that gap with Pilgrim than we are with Kadischi. 3. COMMUNITY DEVELOPMENT. I'd like to see the prominent developers on this list -- Chitlesh, Jasper, jdog, and others I've surely left out -- have commit access. With Anaconda, that simply can't happen. With Pilgrim, it might. === These three facts, in my mind, are reason enough to ask the Fedora Live CD community to consider the benefits of Pilgrim. If we want to develop the two technologies side-by-side, that's fine too. But this is the fedora-livecd-list -- *not* the kadischi list. --g ------------------------------------------------------------- Greg DeKoenigsberg || Fedora Project || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors ------------------------------------------------------------- From dcbw at redhat.com Wed Sep 20 15:44:41 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 20 Sep 2006 11:44:41 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> Message-ID: <1158767081.25941.1.camel@localhost.localdomain> On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote: > On Wed, 20 Sep 2006, David Zeuthen wrote: > > > > If OLPC is a "derived" from Redhat or Fedora Core distribution, I really > > > do not see how this pertains to this list. > > > > I think Rahul answered this already. I'll also note that this is not a > > kadishchi specific list (or at least that's my impression) and several > > people have asked me to specifically post my work here. > > Yes. In fact, I hounded David relentlessly for a couple of weeks to > publicize his work here, because I think it's excellent. > > It's natural to be skeptical of new code, but bear these facts in mind: > > 1. PRIORITY. > > Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a > large superset of Kadischi's. Anaconda also has significant *business* > pressures on its roadmap. Kadischi patches are, therefore, low priority > for Anaconda developers. > > Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. > OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD > is the same. > > 2. INSTALL FUNCTIONALITY. > > If there's one place where Ubuntu has an *actual* lead on us, it's in > their ability to install a Live CD directly to a system. From what I've > seen, we're closer to closing that gap with Pilgrim than we are with > Kadischi. Interesting question; does Ubuntu's LiveCD allow a user to upgrade a currently hard-disk-installed Ubuntu to the Ubuntu version that's booted from the LiveCD, like you would do a clean install? Or do they punt that functionality? Dan > 3. COMMUNITY DEVELOPMENT. > > I'd like to see the prominent developers on this list -- Chitlesh, Jasper, > jdog, and others I've surely left out -- have commit access. With > Anaconda, that simply can't happen. With Pilgrim, it might. > > === > > These three facts, in my mind, are reason enough to ask the Fedora Live CD > community to consider the benefits of Pilgrim. If we want to develop the > two technologies side-by-side, that's fine too. But this is the > fedora-livecd-list -- *not* the kadischi list. > > --g > > ------------------------------------------------------------- > Greg DeKoenigsberg || Fedora Project || fedoraproject.org > Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors > ------------------------------------------------------------- > From davidz at redhat.com Wed Sep 20 15:53:23 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 11:53:23 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <45115AB3.6060704@fedoraproject.org> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> Message-ID: <1158767603.2518.28.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote: > How do you plan on performing upgrades when the live cd gets a install > to hard disk feature? Well, I've written about that in the README.fedora file. Lemme cut'n'paste so people can rip it apart. It's basically just a braindump, I haven't written code for this just yet (patches welcome!). So.. my plan basically just involves running 'yum -y update' in the chroot you install to. Not sure we need any UI, some progress feedback would be nice, not sure if yum can do that already. Seth? Specifically this means that once you boot into the installed OS all updates will have been applied. Clearly this requires network connectivity but such is life. I also expect that it's feasible to do e.g weekly livecd respins we in four months ppl downloading the "FC6 Desktop" livecd will already get the updates minus perhaps a week. But they'll be able to update. > - Can probably start writing the scripts and UI that will wrap libraries > from gnome-diskutil. Suggest this script > This script should > - take some parameters > --target-partition=/dev/sda1 > --install-bootloader-at-mbr=true|false > --fs-label=LabelToUseForFS > [--swap-device=/dev/sda2] > --i18n=da_DK.UTF-8 > --root-passwd (probably safer to pass it on stdin) > - verify that target partition given is large enough > - dd the ext3 fs over to the target partition > - resize2fs the fs > - mount this at /mnt/target > - delete files specific to livecd; that is > - /mnt/target/etc/udev/rules.d/00-livecd.rules > - /mnt/target/etc/init.d/livecd > - /mnt/target/etc/rc5.d/livecd > - (TODO: keep this list in sync with script and with what junk > we put in the pristine ext3 fs.) > - rewrite /mnt/target/etc/sysconfig/i18n > - rewrite /mnt/target/etc/fstab (if no swap device is given use > a swap file on the target fs. No, Swap Files Are Not Evil(tm), > get over it :-) > - run /sbin/mkinitrd in the /mnt/target chroot > - set the root password > - touch a file on /mnt/target so firstboot is run (TODO: need to > either put firstboot on the live cd or make firstboot redundant.) > - write /mnt/target/boot/grub/grub.conf > - run /sbin/grub-install from /mnt/target/ chroot > - run 'yum update' in the /mnt/target chroot if we have network > connectivity. This is to update the installed OS with the latest > security / feature patches etc. etc. > - probably need to include yum-updatesd but disable at livecd usage > since the install system will need it > Also > - script should be invoked via a D-BUS system bus service so the > GUI bits for doing the install become trivial > - provide reasonable progress feedback / error reporting > - need to write this tool with paranoia in mind; we're talking about > messing with people's data here Cheers, David From davidz at redhat.com Wed Sep 20 16:23:30 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 12:23:30 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <45116123.9010804@adelphia.net> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> Message-ID: <1158769410.2518.46.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 10:41 -0500, Jasper Hartline wrote: > David Zeuthen wrote: > > >(adding back fedora-desktop-list as that Cc: field mysteriously > >vanished.) Doing this again. Please don't munge the To: or Cc: headers. Thanks. > >So, you know, I'd hate to replace < 100 lines of code by depending on > >anaconda, which, I might add, is designed to do far more than the > >relatively straightforward task of doing live cd's. I'm not even sure it > >makes sense to carry around code in anaconda to facilitate live cd > >installs but I'll leave that judgement call to the Anaconda developers. > > > > > Ok. Good luck partitioning a disk in any sort of way with Yum. Well, I take it that you are aware that cd media is not normally partitioned (it is for bizarre things like Apple Mac OS X install CD's using Apple Partition Map; but that is totally not relevant for a Fedora Live CD on any architecture we want to support). So I assume you are talking about creating Live USB images, e.g. an image people can dd(1) to the USB key e.g. # dd if=some-image.img of=/dev/sdb where /dev/sdb is the block device for your USB stick. First, pilgrim supports this (partitioning is not hard), it was the first installation target since that is what we use for OLPC; see http://wiki.laptop.org/go/OS_images_for_USB_disks for details. Second, a Fedora system on a USB stick / hard disk is useful.. Heck, this can be done today with the pilgrim system by simple changes to streams.d/fedora-base.stream in the pilgrim source tree (just define a new variant, liveusb, where PILGRIM_FS_liveusb=ext3). The reason I haven't done this is just lack of time. And motivation. The lack of motivation has to do with the fact that I'm not sure how useful it is since ext3 basically is pretty wasteful and have no compression [1]. To have any kind of useful system you'd need a 2GB or bigger stick. Second, I think once we get the "install to hard disk" feature done people can just install the OS to a USB stick / hard disk from the livecd and be done with it. That will also ensure that we fix up the UUID of the file system and other stuff. We can easily add variants for "usb stick" builds until we have the "install to hard disk" feature. But I'd rather that we worked on the latter, that feature is so much more important for Fedora as gdk so eloquently points out. We could also add a new hack to use squashfs / ext3 / dm-snapshot hacks to the live USB image where the overlay lives in a file on a different partition of the USB stick. That way we'd have a semi-useful system that would fit on a 512MB stick. Again, not sure how useful live USB is, I'd rather focus on getting the "install to hard disk" feature done and just tell people to install to a USB stick / harddisk if they want a portable Fedora OS. David [1] : though I did read something about "compressed block devices" being added to Linux. Dunno where that is going. From sundaram at fedoraproject.org Wed Sep 20 16:51:20 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 22:21:20 +0530 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158767081.25941.1.camel@localhost.localdomain> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <1158767081.25941.1.camel@localhost.localdomain> Message-ID: <45117188.9050405@fedoraproject.org> Dan Williams wrote: > On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote: >> On Wed, 20 Sep 2006, David Zeuthen wrote: >> >>>> If OLPC is a "derived" from Redhat or Fedora Core distribution, I really >>>> do not see how this pertains to this list. >>> I think Rahul answered this already. I'll also note that this is not a >>> kadishchi specific list (or at least that's my impression) and several >>> people have asked me to specifically post my work here. >> Yes. In fact, I hounded David relentlessly for a couple of weeks to >> publicize his work here, because I think it's excellent. >> >> It's natural to be skeptical of new code, but bear these facts in mind: >> >> 1. PRIORITY. >> >> Kadischi is heavily reliant upon Anaconda. Anaconda's functionally is a >> large superset of Kadischi's. Anaconda also has significant *business* >> pressures on its roadmap. Kadischi patches are, therefore, low priority >> for Anaconda developers. >> >> Pilgrim, on the other hand, performs *extremely* similar tasks for OLPC. >> OLPC must be imaged very simply, and very uniformly. A Live CD/Live DVD >> is the same. >> >> 2. INSTALL FUNCTIONALITY. >> >> If there's one place where Ubuntu has an *actual* lead on us, it's in >> their ability to install a Live CD directly to a system. From what I've >> seen, we're closer to closing that gap with Pilgrim than we are with >> Kadischi. > > Interesting question; does Ubuntu's LiveCD allow a user to upgrade a > currently hard-disk-installed Ubuntu to the Ubuntu version that's booted > from the LiveCD, like you would do a clean install? Or do they punt > that functionality? > > Dan They punt it currently. Rahul From dcbw at redhat.com Wed Sep 20 17:19:17 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 20 Sep 2006 13:19:17 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158767603.2518.28.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> <1158767603.2518.28.camel@zelda.fubar.dk> Message-ID: <1158772757.26555.36.camel@localhost.localdomain> On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote: > On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote: > > How do you plan on performing upgrades when the live cd gets a install > > to hard disk feature? > > Well, I've written about that in the README.fedora file. Lemme > cut'n'paste so people can rip it apart. It's basically just a braindump, > I haven't written code for this just yet (patches welcome!). > > So.. my plan basically just involves running 'yum -y update' in the > chroot you install to. Not sure we need any UI, some progress feedback > would be nice, not sure if yum can do that already. Seth? > > Specifically this means that once you boot into the installed OS all > updates will have been applied. Clearly this requires network > connectivity but such is life. I also expect that it's feasible to do Right; we certainly can't fit all Fedora Core packages on one LiveCD, since a LiveCD is obviously only _one_ CD. So you'd never be able to upgrade off packages from a CD. Furthermore with Extras its highly likely that people have packages from Extras, and that doesn't fit on a CD either. About the only reasons you might _ever_ want to update from a LiveCD are (a) to test your hardware with the new kernel, and to (b) see what new apps and features are around, before you actually do the update. I don't see what is all that useful about doing the actual update from from the LiveCD itself though, versus rebooting and running a small tool to pull down new .repo files and doing the equivalent of 'yum update' which other tools already do for us. What's the use-case here for update from a LiveCD anyway? Why? Dan > e.g weekly livecd respins we in four months ppl downloading the "FC6 > Desktop" livecd will already get the updates minus perhaps a week. But > they'll be able to update. > > > - Can probably start writing the scripts and UI that will wrap libraries > > from gnome-diskutil. Suggest this script > > This script should > > - take some parameters > > --target-partition=/dev/sda1 > > --install-bootloader-at-mbr=true|false > > --fs-label=LabelToUseForFS > > [--swap-device=/dev/sda2] > > --i18n=da_DK.UTF-8 > > --root-passwd (probably safer to pass it on stdin) > > - verify that target partition given is large enough > > - dd the ext3 fs over to the target partition > > - resize2fs the fs > > - mount this at /mnt/target > > - delete files specific to livecd; that is > > - /mnt/target/etc/udev/rules.d/00-livecd.rules > > - /mnt/target/etc/init.d/livecd > > - /mnt/target/etc/rc5.d/livecd > > - (TODO: keep this list in sync with script and with what junk > > we put in the pristine ext3 fs.) > > - rewrite /mnt/target/etc/sysconfig/i18n > > - rewrite /mnt/target/etc/fstab (if no swap device is given use > > a swap file on the target fs. No, Swap Files Are Not Evil(tm), > > get over it :-) > > - run /sbin/mkinitrd in the /mnt/target chroot > > - set the root password > > - touch a file on /mnt/target so firstboot is run (TODO: need to > > either put firstboot on the live cd or make firstboot redundant.) > > - write /mnt/target/boot/grub/grub.conf > > - run /sbin/grub-install from /mnt/target/ chroot > > - run 'yum update' in the /mnt/target chroot if we have network > > connectivity. This is to update the installed OS with the latest > > security / feature patches etc. etc. > > - probably need to include yum-updatesd but disable at livecd usage > > since the install system will need it > > Also > > - script should be invoked via a D-BUS system bus service so the > > GUI bits for doing the install become trivial > > - provide reasonable progress feedback / error reporting > > - need to write this tool with paranoia in mind; we're talking about > > messing with people's data here > > Cheers, > David > > From sundaram at fedoraproject.org Wed Sep 20 17:34:10 2006 From: sundaram at fedoraproject.org (Rahul) Date: Wed, 20 Sep 2006 23:04:10 +0530 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158772757.26555.36.camel@localhost.localdomain> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> <1158767603.2518.28.camel@zelda.fubar.dk> <1158772757.26555.36.camel@localhost.localdomain> Message-ID: <45117B92.9000407@fedoraproject.org> Dan Williams wrote: > On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote: >> On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote: >>> How do you plan on performing upgrades when the live cd gets a install >>> to hard disk feature? >> Well, I've written about that in the README.fedora file. Lemme >> cut'n'paste so people can rip it apart. It's basically just a braindump, >> I haven't written code for this just yet (patches welcome!). >> >> So.. my plan basically just involves running 'yum -y update' in the >> chroot you install to. Not sure we need any UI, some progress feedback >> would be nice, not sure if yum can do that already. Seth? >> >> Specifically this means that once you boot into the installed OS all >> updates will have been applied. Clearly this requires network >> connectivity but such is life. I also expect that it's feasible to do > > Right; we certainly can't fit all Fedora Core packages on one LiveCD, > since a LiveCD is obviously only _one_ CD. So you'd never be able to > upgrade off packages from a CD. Furthermore with Extras its highly > likely that people have packages from Extras, and that doesn't fit on a > CD either. > > About the only reasons you might _ever_ want to update from a LiveCD are > (a) to test your hardware with the new kernel, and to (b) see what new > apps and features are around, before you actually do the update. I > don't see what is all that useful about doing the actual update from > from the LiveCD itself though, versus rebooting and running a small tool > to pull down new .repo files and doing the equivalent of 'yum update' > which other tools already do for us. This method is not widely documented or easy to use yet AFAIK. > > What's the use-case here for update from a LiveCD anyway? Why? > Basically. My interest in having a install/upgrade from a Live CD is directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia. Fedora is currently 5 CD's/ One DVD and this is expected to grow once when have Fedora Extras on the media too which might be as soon as FC7 since its kind of a prerequisite for this - http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the number of CD's double or even more. A useful desktop set requires the first two CD's in Fedora through the Anaconda method and you can only perform a minimalistic installation from a single CD. Currently we are distributing DVD's in Free media program instead which is a problem in many regions where DVD drivers and media is costly and not widely used. Magazines and books prefer to distribute distributions which have a single CD more often to reduce their costs. There is also a perception of "bloat" related to the number of CD's. In events and for Freemedia distributions it would much more effective to hand out a single live CD with a hard disk installation feature. Of course people might want more software and they would have to grab it off the internet or some other distribution mechanism but a single installalable live CD covers the typical use case and promotional needs. Once this method is propagated and commonly used, users would already have installations which they would want to upgrade later. Having this functionality in a Live CD would mean that I could just forget about Anaconda in Fedora and stick with a Live CD for all my needs which is confined to a desktop and grabbing stuff on demand off the network. Rahul From gmureddu at prodigy.net.mx Wed Sep 20 17:53:46 2006 From: gmureddu at prodigy.net.mx (Gian Paolo Mureddu) Date: Wed, 20 Sep 2006 12:53:46 -0500 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <45117B92.9000407@fedoraproject.org> References: <1158731488.26429.83.camel@zelda.fubar.dk> <"1158764968.2518.19.ca mel"@zelda.fubar.dk> <1158767603.2518.28.camel@zelda.fubar.dk> <45117B92.9000407@fedoraproject.org> Message-ID: <4511802A.5080203@prodigy.net.mx> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rahul escribi?: > > > Once this method is propagated and commonly used, users would > already have installations which they would want to upgrade later. > Having this functionality in a Live CD would mean that I could just > forget about Anaconda in Fedora and stick with a Live CD for all my > needs which is confined to a desktop and grabbing stuff on demand > off the network. > > - From a user's perspective, Anaconda could be used for the "full version", i.e the DVD or full set of CDs composing the totality of Fedora, while you can simply install (I hate saying this, but again, like Ubuntu) from one of the various liveCDs/LiveDVDs... Only prerequisite I see in this approach is to have a means to either: - - have all the necessary .repo files already in place, so when the installation is performed, and the user might want additional software, (s)he could simply fire up pirut, and all the headers would be updated "automagically" and the software retrieved from the repositories; or - - have a minimum set of .repo files, and a routine in yum, so that when either run from the CLI or with pirut or even pup, the necessary repos get installed (sort of a "first-update" operation, a la first boot configuration), and the system updated/ready to install new software. I'd lean more towards the former approach, as simple text files don't take too much space, especially since they can compress so well. The problem would then be deciding which repos to include, as it would rock if livna-release package was available in Extras to be able to grab packages from Livna (with a big Red Flag of Warning, if you will), but sort of make it so that the end users wouldn't have to mess and fetch the keys and packages manually, etc, etc. Just my 2?. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFEYApXM+XOp70dwoRAkAWAJ98SD5B/aLwS6h9+YGmr+y+oXK3nACeOTtI dCwwg0WyYaJIV3lfVllqPlQ= =qGUp -----END PGP SIGNATURE----- From dcbw at redhat.com Wed Sep 20 18:40:50 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 20 Sep 2006 14:40:50 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <45117B92.9000407@fedoraproject.org> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> <1158767603.2518.28.camel@zelda.fubar.dk> <1158772757.26555.36.camel@localhost.localdomain> <45117B92.9000407@fedoraproject.org> Message-ID: <1158777650.27422.8.camel@localhost.localdomain> On Wed, 2006-09-20 at 23:04 +0530, Rahul wrote: > Dan Williams wrote: > > On Wed, 2006-09-20 at 11:53 -0400, David Zeuthen wrote: > >> On Wed, 2006-09-20 at 20:43 +0530, Rahul wrote: > >>> How do you plan on performing upgrades when the live cd gets a install > >>> to hard disk feature? > >> Well, I've written about that in the README.fedora file. Lemme > >> cut'n'paste so people can rip it apart. It's basically just a braindump, > >> I haven't written code for this just yet (patches welcome!). > >> > >> So.. my plan basically just involves running 'yum -y update' in the > >> chroot you install to. Not sure we need any UI, some progress feedback > >> would be nice, not sure if yum can do that already. Seth? > >> > >> Specifically this means that once you boot into the installed OS all > >> updates will have been applied. Clearly this requires network > >> connectivity but such is life. I also expect that it's feasible to do > > > > Right; we certainly can't fit all Fedora Core packages on one LiveCD, > > since a LiveCD is obviously only _one_ CD. So you'd never be able to > > upgrade off packages from a CD. Furthermore with Extras its highly > > likely that people have packages from Extras, and that doesn't fit on a > > CD either. > > > > About the only reasons you might _ever_ want to update from a LiveCD are > > (a) to test your hardware with the new kernel, and to (b) see what new > > apps and features are around, before you actually do the update. I > > don't see what is all that useful about doing the actual update from > > from the LiveCD itself though, versus rebooting and running a small tool > > to pull down new .repo files and doing the equivalent of 'yum update' > > which other tools already do for us. > > This method is not widely documented or easy to use yet AFAIK. > > > > > What's the use-case here for update from a LiveCD anyway? Why? > > > > Basically. My interest in having a install/upgrade from a Live CD is > directly related to http://fedoraproject.org/wiki/Distribution/FreeMedia. > > Fedora is currently 5 CD's/ One DVD and this is expected to grow once > when have Fedora Extras on the media too which might be as soon as FC7 > since its kind of a prerequisite for this - > http://fedoraproject.org/wiki/UnleashKDE. In effect we might see the > number of CD's double or even more. Right; I'm not questioning the use of a LiveCD _install_. I completely agree there. I'm questioning the use of a LiveCD _upgrade_. dan > A useful desktop set requires the first two CD's in Fedora through the > Anaconda method and you can only perform a minimalistic installation > from a single CD. Currently we are distributing DVD's in Free media > program instead which is a problem in many regions where DVD drivers and > media is costly and not widely used. Magazines and books prefer to > distribute distributions which have a single CD more often to reduce > their costs. There is also a perception of "bloat" related to the number > of CD's. > > In events and for Freemedia distributions it would much more effective > to hand out a single live CD with a hard disk installation feature. Of > course people might want more software and they would have to grab it > off the internet or some other distribution mechanism but a single > installalable live CD covers the typical use case and promotional needs. > > Once this method is propagated and commonly used, users would already > have installations which they would want to upgrade later. Having this > functionality in a Live CD would mean that I could just forget about > Anaconda in Fedora and stick with a Live CD for all my needs which is > confined to a desktop and grabbing stuff on demand off the network. But it's not clear to me why you'd want to upgrade from a LiveCD rather than just boot into your already-installed image and do a 'yum upgrade'. There's _nothing_ that a LiveCD-based install process would consist of other than a 'yum upgrade', except that you're running off the livecd. I guess there is a 'seamless' aspect to this, such that you can use the same CD for both the update payload (the new .repo files) and test the hardware in the same bootup. I'm not sure if the small benefit of doing everything in the same boot outweighs the disadvantage of complicating the CD with update logic which could just as easily be done in the real system, since both LiveCD and real system would end up running 'yum upgrade' anyway. Dan From sundaram at fedoraproject.org Wed Sep 20 18:50:25 2006 From: sundaram at fedoraproject.org (Rahul) Date: Thu, 21 Sep 2006 00:20:25 +0530 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158777650.27422.8.camel@localhost.localdomain> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> <1158767603.2518.28.camel@zelda.fubar.dk> <1158772757.26555.36.camel@localhost.localdomain> <45117B92.9000407@fedoraproject.org> <1158777650.27422.8.camel@localhost.localdomain> Message-ID: <45118D71.1090801@fedoraproject.org> Dan Williams wrote: > But it's not clear to me why you'd want to upgrade from a LiveCD rather > than just boot into your already-installed image and do a 'yum upgrade'. > There's _nothing_ that a LiveCD-based install process would consist of > other than a 'yum upgrade', except that you're running off the livecd. Well you to have go grab fedora-release from the latest Fedora, install it and then run yum upgrade and pray that it works. We havent made it very simple nor do we test it explicitly for every release that things work well after a yum upgrade. If we make this very simple for a new user to follow, then maybe we wouldnt need a upgrade through live cd option. Currently, thats not the case. Rahul From davidz at redhat.com Wed Sep 20 19:46:52 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 15:46:52 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158772757.26555.36.camel@localhost.localdomain> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45115AB3.6060704@fedoraproject.org> <1158767603.2518.28.camel@zelda.fubar.dk> <1158772757.26555.36.camel@localhost.localdomain> Message-ID: <1158781612.2518.55.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 13:19 -0400, Dan Williams wrote: > What's the use-case here for update from a LiveCD anyway? Why? I think the question was about upgrading the packages _from_ the livecd when they are installed (if you have an old livecd); not about using the livecd to upgrade an existing installation. For the latter you'd just be using yum [1]. David [1] : Or anaconda... until we fix Fedora etc. to support upgrades from e.g. FC5 -> FC6 using yum - something we badly need anyway and hardly any news From notting at redhat.com Wed Sep 20 20:04:37 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Sep 2006 16:04:37 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158767081.25941.1.camel@localhost.localdomain> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <1158767081.25941.1.camel@localhost.localdomain> Message-ID: <20060920200437.GA5120@nostromo.devel.redhat.com> Dan Williams (dcbw at redhat.com) said: > Interesting question; does Ubuntu's LiveCD allow a user to upgrade a > currently hard-disk-installed Ubuntu to the Ubuntu version that's booted > from the LiveCD, like you would do a clean install? Or do they punt > that functionality? Is this really wanted functonality? I would think that this is much better left to yum/anaconda. Bill From davidz at redhat.com Wed Sep 20 20:07:12 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 16:07:12 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <1158774530.2827.38.camel@localhost> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> Message-ID: <1158782832.2518.70.camel@zelda.fubar.dk> Hi, On Wed, 2006-09-20 at 10:48 -0700, Toshio Kuratomi wrote: > Does pilgrim make an attempt to integrate any of stateless's work? In > my mind integrating stateless with livecd creation just makes sense. > But I don't think there's been much work done on that front since > Jeremy's proof of concept fork of kadischi which I don't think he's been > updating. Nope, I think it's much more elegant to just use dm-snapshot to provide a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people working on stateless team thinks of this, they might have a number of good reasons that I haven't thought out. I still think stateless makes sense for non-livecd work however. Btw, If someone could talk davej into including unionfs into the Fedora kernel, we'd use that instead of dm-snapshot and we'd have persistence more easily solved [1]. David [1] : we can already do this for our livecd but it will be tied to the specific build you're using, e.g. in practice it's tied to the physical media you created it with. With unionfs things might look much better and we'd easily be able to do a harddisk install of "livecd + your changes made" instead of harddisk install becomes contents of "stock livecd", ie. without your changes. That said, I'm not sure that this really matters in real life. From notting at redhat.com Wed Sep 20 20:13:42 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 20 Sep 2006 16:13:42 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <1158782832.2518.70.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> Message-ID: <20060920201342.GD5120@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > Nope, I think it's much more elegant to just use dm-snapshot to provide > a real rw rootfs. Not sure what Bill Nottingham (Cc'ed) or people > working on stateless team thinks of this, they might have a number of > good reasons that I haven't thought out. I still think stateless makes > sense for non-livecd work however. The reason we didn't use dm-snapshot is that it removes the security benefits of readonly-root (after all, you don't need 99% of the system to actually be read-write); moreover, you can't selectively apply it (it has to be done at the whole block device level.) > Btw, If someone could talk davej into including unionfs into the Fedora > kernel, we'd use that instead of dm-snapshot and we'd have persistence > more easily solved [1]. Flaming death. Deadlocks, oopses, etc. (it might be better now) Bill From davidz at redhat.com Wed Sep 20 20:16:56 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 16:16:56 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158773923.2827.32.camel@localhost> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158773923.2827.32.camel@localhost> Message-ID: <1158783416.2518.81.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 10:38 -0700, Toshio Kuratomi wrote: > > Well, I take it that you are aware that cd media is not normally > > partitioned (it is for bizarre things like Apple Mac OS X install CD's > > using Apple Partition Map; but that is totally not relevant for a Fedora > > Live CD on any architecture we want to support). > > > I was confused when I first read autopsy's comment as well. Autopsy, > are you talking about partitioning when creating the liveCD/liveX image? > Or talking about paritioning when installing from liveMedia to a hard > drive? I might add that for the latter, we want to allow the user to create LVM / swap / crypto whatever to install to. That's why we need something like gnome-diskutil that I mentioned in the README.fedora. > I like pilgrim's simplicity. I'm a little hesitant that it's written in > shell (Shell doesn't scale to larger projects nearly as well as python. > Although the original kadischi code had a lot of > reimplementation-of-the-wheel problems.) Shell was chosen as that's the natural language you want to use when defining derivatives. It's simple, lots of people know it and it's very expressive. Btw, I don't expect pilgrim to grow a lot in size and complexity, it's pretty much feature complete except for a few features. For the record, I've written quite a bit of stuff in python but always ended up disliking it - I guess I'm one of the types of programmers that pick extremes. I love writing code in C and think I'm good at it. Shell is pretty useful for stuff like pilgrim. Python always been in the middle for me, I like to call it a "cute" language, but not really useful for the stuff I wanted to do. It always ended up letting me down one way or another. Of course, YMMV, I understand and see that some people use Python in wonderful ways, more power to them. I just don't like it. > I'll have to run pilgrim to see how kadischi and pilgrim differ in real > usage. Let me know if you need help. I tend to hang out on #fedora-desktop on GimpNet and #freedesktop on freenode as davidz. I suppose this list if fine to use too. David From davidz at redhat.com Wed Sep 20 20:40:52 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 20 Sep 2006 16:40:52 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> Message-ID: <1158784852.2518.89.camel@zelda.fubar.dk> On Wed, 2006-09-20 at 11:29 -0400, Greg DeKoenigsberg wrote: > I'd like to see the prominent developers on this list -- Chitlesh, Jasper, > jdog, and others I've surely left out -- have commit access. With > Anaconda, that simply can't happen. With Pilgrim, it might. Sure, I'm all for that and am hopeful to get contributors besides myself. Would have to review patches etc. on list since other projects such as OLPC depends on pilgrim. But that's no different from other open source projects. The first step towards that, and something I'd like anyway, is moving the pilgrim git repository from my home directory on freedesktop.org to Fedora infrastructure. Any pointers to how I do that? Thanks. David From chitlesh at fedoraproject.org Wed Sep 20 22:07:45 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 21 Sep 2006 00:07:45 +0200 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> Message-ID: <13dbfe4f0609201507i2354727fx5b956af4399a944a@mail.gmail.com> On 9/20/06, Greg DeKoenigsberg wrote: > These three facts, in my mind, are reason enough to ask the Fedora Live CD > community to consider the benefits of Pilgrim. If we want to develop the > two technologies side-by-side, that's fine too. But this is the > fedora-livecd-list -- *not* the kadischi list. This was the main reason why I've asked Fedora Board to ping David for more info about pilgrim in this list ! :) Chitlesh -- http://clunixchit.blogspot.com From chitlesh at fedoraproject.org Wed Sep 20 22:31:31 2006 From: chitlesh at fedoraproject.org (Chitlesh GOORAH) Date: Thu, 21 Sep 2006 00:31:31 +0200 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <1158784852.2518.89.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <1158784852.2518.89.camel@zelda.fubar.dk> Message-ID: <13dbfe4f0609201531u159bc1b8q847ea577d395ac29@mail.gmail.com> On 9/20/06, David Zeuthen wrote: > Sure, I'm all for that and am hopeful to get contributors besides > myself. Would have to review patches etc. on list since other projects > such as OLPC depends on pilgrim. But that's no different from other open > source projects. After reading all these mails :), i'll tend to say that pilgrim's yum approach sounds great. Yum's new metaparser might play a great role as well. However, anaconda provides kickstart file feature to kadischi and this is greatly used by people in the fedora-livecd list. Sure, I'm not saying that kadischi has to adapt itself to pilgrim's theory. But since, kadischi is only maintained for the moment by Jasper and I at a very slow rate, it would be best to consider on what * what is Kadischi, by the Fedora Project * which one should be a Fedora Live image Creator/Installer * how both pilgrim and kadischi can benefit. Ill try pilgrim this weekend. > The first step towards that, and something I'd like anyway, is moving > the pilgrim git repository from my home directory on freedesktop.org to > Fedora infrastructure. Any pointers to how I do that? Thanks. > is it possible to have under svn ? :p i've cvs access blocked over my place. David, is your presentations available for download ? I'll like to have a look at them :) Chitlesh -- http://clunixchit.blogspot.com From davej at redhat.com Thu Sep 21 00:20:48 2006 From: davej at redhat.com (Dave Jones) Date: Wed, 20 Sep 2006 20:20:48 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <1158782832.2518.70.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> Message-ID: <20060921002048.GA31935@redhat.com> On Wed, Sep 20, 2006 at 04:07:12PM -0400, David Zeuthen wrote: > Btw, If someone could talk davej into including unionfs into the Fedora > kernel, we'd use that instead of dm-snapshot and we'd have persistence > more easily solved [1]. I think the comments Al Viro had on it the last time it was reviewed were for the most part unprintable. I wouldn't hold your breath for this to appear any time soon. Dave From skvidal at linux.duke.edu Thu Sep 21 00:33:06 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 20 Sep 2006 20:33:06 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <13dbfe4f0609201531u159bc1b8q847ea577d395ac29@mail.gmail.com> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <1158784852.2518.89.camel@zelda.fubar.dk> <13dbfe4f0609201531u159bc1b8q847ea577d395ac29@mail.gmail.com> Message-ID: <1158798786.19833.11.camel@cutter> On Thu, 2006-09-21 at 00:31 +0200, Chitlesh GOORAH wrote: > On 9/20/06, David Zeuthen wrote: > > Sure, I'm all for that and am hopeful to get contributors besides > > myself. Would have to review patches etc. on list since other projects > > such as OLPC depends on pilgrim. But that's no different from other open > > source projects. > > After reading all these mails :), i'll tend to say that pilgrim's yum > approach sounds great. Yum's new metaparser might play a great role as > well. However, anaconda provides kickstart file feature to kadischi > and this is greatly used by people in the fedora-livecd list. > > Sure, I'm not saying that kadischi has to adapt itself to pilgrim's > theory. But since, kadischi is only maintained for the moment by > Jasper and I at a very slow rate, it would be best to consider on what > > * what is Kadischi, by the Fedora Project > * which one should be a Fedora Live image Creator/Installer > * how both pilgrim and kadischi can benefit. > implementing a %packages in ks.cfg-style parser as a yum-util shouldn't be much work. Mostly just extracting the code from anaconda, I'd bet. -sv From davidz at redhat.com Thu Sep 21 20:16:54 2006 From: davidz at redhat.com (David Zeuthen) Date: Thu, 21 Sep 2006 16:16:54 -0400 Subject: [Fedora-livecd-list] pilgrim livecd work In-Reply-To: <13dbfe4f0609201531u159bc1b8q847ea577d395ac29@mail.gmail.com> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <1158784852.2518.89.camel@zelda.fubar.dk> <13dbfe4f0609201531u159bc1b8q847ea577d395ac29@mail.gmail.com> Message-ID: <1158869814.2622.66.camel@zelda.fubar.dk> On Thu, 2006-09-21 at 00:31 +0200, Chitlesh GOORAH wrote: > Ill try pilgrim this weekend. Thanks! > > The first step towards that, and something I'd like anyway, is moving > > the pilgrim git repository from my home directory on freedesktop.org to > > Fedora infrastructure. Any pointers to how I do that? Thanks. > > > > is it possible to have under svn ? :p i've cvs access blocked over my place. Oh, I'm suggesting to use git. That, AFAIK, can be tunneled over ssh which shouldn't be a problem from your place? (I think it can also be tunneled over http, not sure.) > David, is your presentations available for download ? I'll like to > have a look at them :) Presentations? Do you mean the ISO, that one is here http://olpc.download.redhat.com/olpc/fedora-desktop-davidz-stream-development-build-2-20060919_2225-livecd.iso or anything else? Cheers, David From davidz at redhat.com Fri Sep 22 00:31:48 2006 From: davidz at redhat.com (David Zeuthen) Date: Thu, 21 Sep 2006 20:31:48 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <20060921002048.GA31935@redhat.com> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> <20060921002048.GA31935@redhat.com> Message-ID: <1158885108.2440.71.camel@zelda.fubar.dk> Hey Dave, On Wed, 2006-09-20 at 20:20 -0400, Dave Jones wrote: > On Wed, Sep 20, 2006 at 04:07:12PM -0400, David Zeuthen wrote: > > > Btw, If someone could talk davej into including unionfs into the Fedora > > kernel, we'd use that instead of dm-snapshot and we'd have persistence > > more easily solved [1]. > > I think the comments Al Viro had on it the last time it was reviewed > were for the most part unprintable. I wouldn't hold your breath for > this to appear any time soon. Right. My understanding is that the controversial part of unionfs is the ability to join multiple writable file systems into a single tree. Is this correct? If so, note that this is not a feature livecd nor stateless needs, the one part is always read-only, the other parts is just a single overlay where we take damage. How hard would it be to do a unionfs-ro (read only) with the following semantics 1. Support exactly two underlying directories, the first assumed to be read only 2. If some file exists in both trees, pick file with latest ctime I dunno much about the kernel VFS layer to say whether this is easy or hard but I do hope this is a lot simpler than what current unionfs is doing. So.. is this hard? Btw, justification for 2. ("pick file with latest ctime", not just "if file exist in rw branch, always pick rw branch"): suppose I use a livecd using this unionfs-ro fs and updates my bash package. The changes are now written to a USB stick such that I have a persistent session. I now download a newer version of the livecd where the bash package is newer. When using this together with my USB stick, we'll pick the newest /bin/bash file. David From davej at redhat.com Fri Sep 22 00:47:25 2006 From: davej at redhat.com (Dave Jones) Date: Thu, 21 Sep 2006 20:47:25 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <1158885108.2440.71.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> <20060921002048.GA31935@redhat.com> <1158885108.2440.71.camel@zelda.fubar.dk> Message-ID: <20060922004725.GA18338@redhat.com> On Thu, Sep 21, 2006 at 08:31:48PM -0400, David Zeuthen wrote: > On Wed, 2006-09-20 at 20:20 -0400, Dave Jones wrote: > > On Wed, Sep 20, 2006 at 04:07:12PM -0400, David Zeuthen wrote: > > > > > Btw, If someone could talk davej into including unionfs into the Fedora > > > kernel, we'd use that instead of dm-snapshot and we'd have persistence > > > more easily solved [1]. > > > > I think the comments Al Viro had on it the last time it was reviewed > > were for the most part unprintable. I wouldn't hold your breath for > > this to appear any time soon. > > Right. My understanding is that the controversial part of unionfs is the > ability to join multiple writable file systems into a single tree. Is > this correct? tbh, since Al reviewed it unfavorably, I haven't even bothered looking at it, so I'm the wrong person to be asking. But ISTR there were a number of issues rather than one sticking point. Al would be a better person to ask about the gory details. Dave From notting at redhat.com Fri Sep 22 01:26:31 2006 From: notting at redhat.com (Bill Nottingham) Date: Thu, 21 Sep 2006 21:26:31 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <1158885108.2440.71.camel@zelda.fubar.dk> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> <20060921002048.GA31935@redhat.com> <1158885108.2440.71.camel@zelda.fubar.dk> Message-ID: <20060922012631.GD20578@nostromo.devel.redhat.com> David Zeuthen (davidz at redhat.com) said: > Right. My understanding is that the controversial part of unionfs is the > ability to join multiple writable file systems into a single tree. Is > this correct? Well, in my experience, all I tried was one readable + one writable, and *that* blew up. So, my objection was that the basic case failed. Bill From davidz at redhat.com Fri Sep 22 01:39:13 2006 From: davidz at redhat.com (David Zeuthen) Date: Thu, 21 Sep 2006 21:39:13 -0400 Subject: Pilgrim, kadischi, and stateless (was Re: [Fedora-livecd-list] pilgrim livecd work) In-Reply-To: <20060922012631.GD20578@nostromo.devel.redhat.com> References: <1158731488.26429.83.camel@zelda.fubar.dk> <4510F64E.4070207@adelphia.net> <1158764968.2518.19.camel@zelda.fubar.dk> <45116123.9010804@adelphia.net> <1158769410.2518.46.camel@zelda.fubar.dk> <1158774530.2827.38.camel@localhost> <1158782832.2518.70.camel@zelda.fubar.dk> <20060921002048.GA31935@redhat.com> <1158885108.2440.71.camel@zelda.fubar.dk> <20060922012631.GD20578@nostromo.devel.redhat.com> Message-ID: <1158889153.2440.103.camel@zelda.fubar.dk> On Thu, 2006-09-21 at 21:26 -0400, Bill Nottingham wrote: > David Zeuthen (davidz at redhat.com) said: > > Right. My understanding is that the controversial part of unionfs is the > > ability to join multiple writable file systems into a single tree. Is > > this correct? Just found the page here, http://www.am-utils.org/project-unionfs.html And yes, it appears it's designed to do a lot of things instead of just doing one thing really well. > Well, in my experience, all I tried was one readable + one writable, and > *that* blew up. So, my objection was that the basic case failed. I'm more curious how hard it can be given the assumptions I listed in my other mail. Then again, I'm not a kernel hacker and got too much on my plate already :-) David From splinux at fedoraproject.org Sat Sep 23 20:39:13 2006 From: splinux at fedoraproject.org (Damien Durand) Date: Sat, 23 Sep 2006 22:39:13 +0200 Subject: Fedora tools don't give credits to translators In-Reply-To: <1159035193.6358.23.camel@localhost.localdomain> References: <451554CD.9000803@glezos.com> <1159035193.6358.23.camel@localhost.localdomain> Message-ID: Maybe the fedora usability sig can take a look on this. This can be a good point for starting contributions ;-) 2006/9/23, Paul W. Frields : > > On Sat, 2006-09-23 at 16:37 +0100, Dimitris Glezos wrote: > > Hello all, > > > > I just noticed that some of the system-config-* applications do not have > a > > "Help" -> "About" -> "Credits" -> "Translators" menu, which is there to > give > > credit to translators of the particular locale. All GNOME applications > that I > > have seen do have this menu item. I suggest we incorporate this too. > > > > In the "About Fedora" dialog, there is a link saying "visit our website > at > > http://fedora.redhat.com/About/Projects/translations/". Shouldn't that > be > > changed to link to the wiki? > > Yes. During the last cycle, Translation had not yet moved any content > to the wiki. That's all changed and so I have fixed this link. > > -- > Paul W. Frields, RHCE http://paul.frields.org/ > gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 > Fedora Project Board: http://fedoraproject.org/wiki/Board > Fedora Docs Project: http://fedoraproject.org/wiki/DocsProject > > > -- > Fedora-trans-list mailing list > Fedora-trans-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-trans-list > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From minsonj at spawar.navy.mil Wed Sep 27 14:42:30 2006 From: minsonj at spawar.navy.mil (John Minson) Date: Wed, 27 Sep 2006 10:42:30 -0400 Subject: duplicate KDE desktop icons Message-ID: <451A8DD6.6010807@spawar.navy.mil> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minsonj.vcf Type: text/x-vcard Size: 57 bytes Desc: not available URL: From rdieter at math.unl.edu Wed Sep 27 15:06:15 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 27 Sep 2006 10:06:15 -0500 Subject: duplicate KDE desktop icons References: <451A8DD6.6010807@spawar.navy.mil> Message-ID: John Minson wrote: > why do I get 2 desktop icons for my firewire harddrive ? Does it have 2 partitions? (: -- Rex From minsonj at spawar.navy.mil Thu Sep 28 11:23:10 2006 From: minsonj at spawar.navy.mil (John Minson) Date: Thu, 28 Sep 2006 07:23:10 -0400 Subject: duplicate KDE desktop icons In-Reply-To: References: <451A8DD6.6010807@spawar.navy.mil> Message-ID: <451BB09E.2020509@spawar.navy.mil> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minsonj.vcf Type: text/x-vcard Size: 57 bytes Desc: not available URL: From minsonj at spawar.navy.mil Thu Sep 28 11:37:44 2006 From: minsonj at spawar.navy.mil (John Minson) Date: Thu, 28 Sep 2006 07:37:44 -0400 Subject: duplicate KDE desktop icons In-Reply-To: References: <451A8DD6.6010807@spawar.navy.mil> Message-ID: <451BB408.3060702@spawar.navy.mil> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: minsonj.vcf Type: text/x-vcard Size: 57 bytes Desc: not available URL: