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

[Les Mikesell]

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

>> 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 at gmail.com