[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: WSJ: Mossberg takes the Linux bait and snarls ....

Andrew Kelly wrote:

Oh, you're talking about a completely new package manager. I thought you
just meant something standalone which would/could export a config,
basically building a better mousetrap in a kickstart sense of things.
That's a start - I'd probably do an extremely minimal kickstart install followed by a yum install of a complete packagelist generated by some invocation of 'rpm -q' on the master machine. But the install isn't quite the point. I want to be able to track subsequent changes on that master machine over the next many years at whatever interval the admin exports updated lists, and I want to be able to switch to duplicate some different master at any time.

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.

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.

You in, too? Or are you in more of a "peel me another grape" place right
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.

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 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?

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. 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. 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.

  Les Mikesell
   lesmikesell gmail com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]