Hi Les, I think we're looking at this horse from different ends. Or at the very least, I've quite misunderstood whichever of your statements prompted me to join this dialogue. On Thu, 2007-09-20 at 08:23 -0500, Les Mikesell wrote: > Andrew Kelly wrote: > > Right off the top of my head, I don't see this playing out without a > > complete restructuring of repositories. Read that to mean that packages > > (be they .deb, .rpm, .nameTheNewAnimal, whatever) are going to have to > > have a new naming convention. Every repackaging is going to have to be > > uniquely identifiable and (more importantly) indefinitely available. > > There would be limits, but I think it would be possible using the way > the Centos repositories work within the span of a release - which is > pretty long. The version-numbered packages just accumulate although they > periodically shuffle old updates out to an archive repository. However > I'd probably investigate the features of rpath's conary package manager > before re-inventing anything. I haven't really used it yet but it > sounds more comprehensive than the others. > > > Your "master" machine is also going to have to take on the burden of > > accuracy in minutiae. It will have to maintain a local DB of diffs on > > its config files vs the packaged config files and export that material > > as well so that any non-default local changes are also duplicated. > > That's the point of this exercise. Getting details right is something > that computers are supposed to be good at. Keep in mind that without > this system thousands (millions?) of people are doing this work by hand > and probably getting much of it wrong. > > > And of course any locally compiled source installs will have to be part > > of the kit. > > I'd expect packaging to be standardized and if a master required > packages or versions not in the stock repository an additional > repository would be provided to hold them. They would be packaged and > installed from the package onto the master. Remember, we are expecting > an expert to be configuring the master, so we'll expect this to be done > right. And here's where we part company, I think. Even though you've commented somewhat negatively about developers putting their efforts into distributions, that's clearly what you're talking about here. Lot of morphing going on, or I'm just frazzled at the end of a long week. Lemme see if I can recant how I followed things; apologies in advance if I get it wrong. You said roughly, ".. a tool that can reproduce a particular installation. Joe Blow can 'export' his setup, and the next day everybody could be using the 'Joe Blow Setup'. I said, ".. sounds great, I'm interested, is anybody working on something like that, let's build it." You said, ".. everybody hammering away at new distro (names), spinning CDs, setting up incompatible repos, when they should collaborate on a proper package manager." I said, ".. oh, you want a new package manager, I thought you just wanted the ability to export a working setup so 'consumers' could duplicate it. Whatever, I'm still interested, are you in?" And then you said what's hanging several paras above this line, which reads to me like you're now talking about a distro, and a flipping well-managed one at that. That's a long, (long) way from, "everybody can click a URL and be using the Mossburg Whizbang by nightfall". I appreciate a great deal of your contributions here, Les, but at this point I have to give a bit of credence to those who say you only bellyache about "this doesn't do what I want". I'm not meaning to be pissy, please don't read it like that. But can you see how I might have gotten into my confusion zone here? Now, back to the original stimulant, namely, export of installation and such. I continue to believe this is a great idea, but it cannot be a managed thing like you've described above. That is clearly the bailiwick of a full blown Linux Distribution. The 'export' (for lack of a better term right now) would have to be available to everybody. That's the sexy part and the whole attention-getter. Being able to make any installation whatsoever, completely reproducible for anybody else. Think of it like, what..... php apps. Everybody and their uncle diddles with php and there are metric tons of scripts and apps out there for all and sundry. They run the spectrum from "dung" to "suitable for enterprise deployment". I respect your desire for the latter, and surely it would evolve, but you must also make way for the former. That's why accommodations must also be made for "local installs from source". You follow? > >>> Whatever. I'm in, either way. > >>> I've been looking for something of that magnitude as an anchor project > >>> in a long-term thing I'm currently conceptualising. > >> The big problem would be having a stable repository containing all > >> needed packages in all versions that might be referenced by any > >> packagelist and a place to upload the master lists. > > > > That's just logistics. The booger will be the two outermost points of > > the relationship: the "export" and the "import". > > Have you looked at rpath's appliance builder? The builder portion isn't > free but I think the rest of the tools are. And automating the initial > build isn't quite the goal. It should be to roll out working clones of > an expertly hand-built system and do all subsequent maintenance. Managed distro, with support agreement. That wheel has been rolling a long time. OK, I presume that you'll counter the distro argument with the fact that 7 bazillion packages won't be delivered. So let's call it a slim distro. But what happens when somebody finds that particular flavor to be ALmost perfect, but find the need to install an obscure statistics program and a special, hacked port of Pine? And by the way, doesn't all of this smell a bit like Ubuntu in the first place? > >>> You in, too? Or are you in more of a "peel me another grape" place right > >>> now? > >> I'm not in a position to write a lot of code or provide the repository > >> space, > > > > In all honesty, neither am I in the current near and mid-term. I may > > have opened my yap a bit wider than it could actually accommodate. But > > it's certainly something I'm going to pursue eventually. > > > >> but I've sampled a lot of grapes and can comment on which are > >> suitable for general consumption. > > Ach, that particular pool is thousands deep. There'll be no end to the > > flow of useful and well-meant input. > > I have the experience of actually keeping hundreds of machines working > over many years, though. I don't know everything, but I know some > things that work, and a lot that don't. You know, I'm convinced that your disto (we'll call it Lesnix), would actually be something that I would probably immediately call my favorite. Regardless of where this current discussion has gone, I'm more than keen to collaborate with you on something of this nature. Alas, I probably don't have sharp enough teeth in many areas, but I'm certain it wouldn't be just the two of us anyway. > >> Personal opinion again, but the thing > >> that makes unix-like systems unsuitable for personal desktop use is that > >> there is just too much administration involved if everyone has to do it > >> all individually - and a few dozen expertly installed/maintained systems > >> could handle virtually everyone's desktop needs as long as the ability > >> to add new packages is still available. > > > > I see your gist here, but it's all really relative, innit? I mean > > really, the lion's share would love to have a manservant to dress them > > everyday, but most of us dress ourselves, non? Most of us do it by > > necessity, of course, but there are not a few who do it by choice alone. > > That's not a great analogy. Unix was really designed to be used in a > multiuser situation where a site administrator would be expected (and > needed). Back when computers were expensive, that made sense. The > problem is that administration hasn't gotten any easier now that > everyone can afford their own machine but not an administrator. I can think of 2 quick remedies to that quandary. 1. If you can't administer it yourself, you shouldn't have it, get something else. 2. Hire somebody who can administer it for you. That's the mid-term cash cow in the Linux namespace anyway. Think of tens of thousands of Karl Larsens who don't have his intelligence, or his tenacity or desire to learn. They are displeased with the status quo, but will never be able to (for example) manipulate sendmail.conf by hand. So they might be well suited by paying a subscription fee for remote admin of their workstations. > > I disagree that there is too much admin involved. Personally, I choose > > to be in this namespace precisely because of the admin. The market is > > saturated with TSFOS (The Spoon-Fed Operating System), and I am tickled > > to have an OS available to me over which I can have total control. I'm > > likely in a rather small minority, but I have no interest in "driving > > your car" so to speak. There might be certain aspects of somebody else's > > installation which would interest me, but I could never envision myself > > wanting to have the exact set-up as Bob or Larry or Whomever. > > I'm not talking about driving a car, I'm talking about customizing a car > which might sound like fun but very few people really want to do it > themselves. Even if the car factory has an updated part for their car, > most people will let the dealer bolt it on instead of hoping they get it > right themselves without any prior experience. You aren't a typical > computer user, though. Think of it the other way around. Could you > build a system that would be suitable for Bob/Larry for some particular > use, and if it is good for them, how many other people might it suit? How on earth would I know what Bob or Larry might deem suitable? Good heavens, in this list alone I see LPIC-1 level users having issues with items I'd never think to install on my personal box. Throw an exponent on that and you're looking at a big pile of need. It'll take more than two and a half volunteers to master that one, Les, as I'm sure you're well aware. But, yes, I do hear you. > >> But "maintained" is the > >> operative word there - when the master updates or changes package > >> versions the copies need to track the changes over the life of the machine. > > > > Another can of worms at the consuming end would be the issues of staying > > up to date versus some kind of point-in-time cloning. > > Apple probably has the most popular unix-based desktop around. You know, an Apple and several fathoms of half-inch chain, and you've got yourself a pretty passable boat anchor. I'll change professions before I sit again at one of those. > It isn't > quite comparable to Linux in that they limit the range of hardware. But > consider this feature: if you buy a new Mac, you can connect it to your > old one via firewire and it will migrate over all of your old accounts, > settings, and data. Note that this works even across different > processor types. For example it will migrate the ppc version of MS > office to an intel mac along with all the files, and it will run there. If you had such a small market share and your products were so disproportionately overpriced and your target consumer was so ill equipped to handle technology, I'm pretty certain you'd make every effort to ensure that every bell rang and every whistle tooted, too. Sheesh! Again, though, I follow your actual point. > That's probably too much to ask for Linux but automatic migration > within a processor type line seems reasonable. And if you can do it > once, you should be able to repeat it any number of times for things > where the license allows. Everything is possible, Les, it's just a matter of available resources. At any rate, I've rambled far too long and still have far too much to do. As I said, I'm keen to put heads together, so don't think I'm just being combative. Nice weekend to you, (and whomever might read this). Andy
