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

[Les Mikesell]

Andrew Kelly wrote:

>>>> That's almost the model that I foresee actually working for whatever 
>>>> unix-like system implements it first.  Make the package manager just a 
>>>> bit smarter and add a 'publish' button somewhere so a person who had 
>>>> configured a nicely working system could export his installed package 
>>>> list and custom configuration settings, and it would result in a URL 
>>>> that anyone else could click to duplicate that setup slightly more 
>>>> closely than matching kickstart installs would.   That way someone could 
>>>> tweak a machine to someone like Mossberg's satisfaction, he could push a 
>>>> button, and the next day a million people could be running "Mossberg's 
>>>> recommended Linux".  Or the same for someone who actually knows how to 
>>>> configure a linux box...
>>> Outstanding idea, Les. You know if anybody is currently working on
>>> anything like that?
>> No, everyone wants to make up new distribution names, spin CD's and 
>> build incompatible repositories instead of cooperating and making a 
>> package manager smart enough to do this.
> 
> 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.

Yum could almost do this, given repositories containing all of the 
needed packages/versions but would need some help in terms of rolling 
local config changes on the master into some sort of packages and 
dealing with which packages and config items are really local (hostname, 
ip address, etc.), which are hardware related, and which can be 
duplicated. In my opinion, local/hardware/software-virtual settings 
should never have been put in the same files to start with, but...

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

> 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, but I've sampled a lot of grapes and can comment on which are 
suitable for general consumption.  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.  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.

-- 
   Les Mikesell
    lesmikesell at gmail.com