On 08/01/2013 04:38, Michael K. Johnson wrote: > On Sun, Jan 06, 2013 at 03:46:48PM +0100, Rune Morling wrote: >> As I understood it, when I asked about Michael's idea of an ideal FL >> base system, he mentioned how in his view RH is moving too slow, while >> fedora is perhaps sometimes too close to the bleeding/experimental edge >> for comfort. To me it sounded as if he was aiming for a base system that >> approaches the stability of RH but uses conary to retain agility and >> approaches the modernity (if perhaps sometimes prematurely so) of the >> fedora base. As I understand it, António has long wanted something similar. > I would like the control of conary to provide rolling updates, with > updates available faster than RHEL, but without forcing everyone to > the bleeding edge. I think that's pretty close to what you said. :) > > Basically, Foresight started as a GUI wrapper around rPath Linux. > Then when rPath Linux became essentially unmaintained, thanks to > Conary, Foresight was able to pick up maintenance of individual > pieces one at a time. But sometimes that maintenance has assumed > that the GUI layer exists, so the dependency web for a minimal > system is larger than I'd like. So I'd like to have a more separate > base OS again, even though developed under the same umbrella.
I really would like to see this as creating Server images will be a really good idea and I believe that FL will become more used in that space if we do have something like that. I am thinking canned VM's for production servers, Rails, Django, etc. that you push out to EC2, openstack vmware etc.. (if we still are alowed to ) My Bongo repo would then become quite useful as well :-) So I am super excited that this is even being considered. > >> Self-contained, text-only system which leverages recent plumbing work >> and uses dracut and systemd and much of the fedora base where it makes >> sense, such as bash, gcc, glibc, kernel (including DRM/KMS drivers and >> firmware) etc. If we use a fedora-ish base system, we can also leverage >> fedora user-management GUI tools. Given my experience with hacking on >> the GNOME user management tools, this is frankly a far more appealing >> prospect for me. > Very much so. In general, being able to use binaries built for RHEL > (that is, having a compatible set of core libraries available even > if there are also newer libraries available) will make it more appealing > as a core OS. Yes I agree. > > There is a lot of momentum in the direction of systemd. I don't have > expertise debugging it (yet?) but it certainly contributes both to > isolation and fast boot, two things I think would be valuable. > > The move to dracut made booting more reliable. It was really nice > for creating generically-bootable images; I can easily build a tarball > with a universal (relatively speaking, anyway) initrd that will boot > on lots of systems. > > -- > > We don't have to limit ourselves to only one of everything. We do > not need to implement the "alternatives" system; as I see it, > conary's system model removes the need for that system and > replaces it with "available" packages that might be installed, but > don't have to be installable together. > >> - Whatever smtpd mkj needs/likes (so probably sendmail, though I have >> mostly used postfix myself) > We clearly need sendmail and postfix both. I know more about sendmail > but that doesn't mean I'm anti-postfix; I should probably convert > lists.foresightlinux.org over to postfix so that it can handle automatically > adding aliases to make it easier to add lists. We were just in a bit of > a hurry to get things going initially, and there are more important tasks > to work on right now. And probably some people want exim too. Yes all three SMTP agents would be a plus, at least that they are available to install. > >> - one and only one traditional syslog daemon (rsyslog or syslog-ng) with >> a reasonable default setup, including sensible log-rotation > We already use rsyslog. > >> - Postgresql (it is not entirely clear to me whether MySQL or MariaDB >> are a hard requirement for some people these days?) > Again, we don't have to standardize on a single database. If I had > to choose one it would be postgresql, and that's what I'll be involved > in updating; probably multiple versions available simultaneously because > of how postgresql works (I build 9.2 on a separate label so that we can > use it for infrastructure, without upgrading major versions on a conary > label). But if someone wants also to have mysql or mariadb, more power > to them. Again if they are available to install then :-) > >> I'd prefer if we could use plymouth with dracut and systemd, but I know >> that Michael has had a less-than-ideal experience with plymouth and has >> been known to disable it on his local systems. From my fedora >> experience, it seems that fedora has a pretty good handle on how to make >> it work like it should, so at this point I personally consider it a >> fairly well-understood and stable piece of tech. > I'm weird. I like to see kernel boot messages. This hasn't changed > since rhgb (remember that?) and splashy. As long as it is optional, > I'm happy. But then, I'm deploying systems under virtualization > where plymouth is just extra useless bytes much of the time. Note > that most of the foresight infrastructure is now deployed using > virtual infrastructure, so we have a close-to-home use case for > leaving it out. I like boot loader messages as well :-) perhaps if we make it so that it is optional then that would cover both use cases? > >> Bootloader: >> >> I much prefer the simplicity of the Syslinux config over what I perceive >> to be the frankly bizarre complexity of GRUB 2. As I understand it, > Preach it, brother! > > It it weren't for pvgrub, I'd almost be happy to drop grub support > entirely. With EFI support coming, I think we'll be mostly in good > shape. > > The next challenge is, of course, secure boot. > >> How far off base am I in the above? Am I the only one who would like to >> see FL develop along the lines laid out here? How do you guys see the >> new and improved FL? > I want to keep packages on separate labels from groups, so that we do not > promote packages. That means that promotes will be very quick since the > packages won't be rewritten. It also means that migrating a system between > Devel, QA, and Release labels will be a small and reasonable operation, > not significantly different from any "updateall" operation. With system > model, there just isn't a need to promote packages; the groups control > the update process. > > An open question is whether to have separate labels for the base, core > OS labels and for the GUI bits wrapped around it. With GroupSetRecipe, > cooking the recipe won't take nearly so long. My gut feeling is to have > one source group and one set of labels for all levels of the OS, on the > theory that there isn't really a lot of value in pulling them apart, > and that to do so would also create additional steps in rolling fixes > and updates out across the levels. I like the idea of using groups to pick your OS level to start your project with. as we did woth the Bongo images in the days of Yore. so the base is as small as possible and then just what is needed is added. I am not sure if this is what you mean or how you mean it but I REALLy liked making images with RPL before we had to move off. Thanks again to everyone for all the work on making things happen here in the community. _______________________________________________ Foresight-devel mailing list Foresight-devel@lists.rpath.org http://lists.rpath.org/mailman/listinfo/foresight-devel
