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

Les Mikesell lesmikesell at gmail.com
Fri Sep 21 14:59:31 UTC 2007


Andrew Kelly wrote:

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

Maybe - but there are some piecemeal things that could be done if you 
are looking for a project.


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

The negative aspect is about the effort being put into different 
distributions being compartmentalized.  That is, if each distro has one 
great but different feature, you can't have both at once.  I'm looking 
for a mechanism where the effort can go into producing compatible 
packages, a technical user can create any combination he considers 
useful and has a way to export his configuration so a non-technical user 
clone it for the asking.

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

Yes, at the simplest level, think of doing an 'rpm -qa' in some 
appropriate format from a working machine, tossing that list in a cvs 
repository where anyone could check out any version you had committed, 
and tell yum to install that package set for you.  You'd also need a 
place to describe the great features of your particular setup and 
perhaps a way for others to rate it to help distinguish among setups. 
The catch is that yum can't sort out the hardware differences between 
machines.  Then there are some local configuration edits that you'd like 
propagate and some that you can't.

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

I want a mechanism capable of duplicating a setup where there is no 
particular relationship between the people maintaining the packages, the 
people exporting master definitions, and the people using those master 
definitions to reproduce tested, known-working setups. That doesn't 
quite fit the definitions of either a package manager or a distribution 
as we think of them now, but it isn't far off either.

> That's a long, (long) way from, "everybody can click a URL and be using
> the Mossburg Whizbang by nightfall".

No, if the mechanism works, that would be the result.

> 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 don't object to the concept of free software as stuff that someone 
wrote for themselves without regard to usefulness to others, but these 
days there is the appearance of wanting to compete with commercial 
versions.  I don't mean to offend those in the first category but I 
don't expect them to care either - but the latter needs to care about 
what people 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?

Yes, much of what I write is complaints about things that don't work the 
way I'd like them to work.

> 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 a way to describe the packages in text and commit the list to a 
version control mechanism like cvs, subversion, or git.  Then not only 
can anyone reproduce a copy, they can reproduce a copy of any version 
you've ever committed and easily see the differences.  With a bit of 
thought about branching a base version, you might also be able to easily 
see the differences between different systems in the same way as the 
history of one.

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

I don't object to a full-blown 'local compile' system but I don't think 
it is necessary either.  If someone isn't capable of wrapping his build 
into a package (this would be writing a spec file in the rpm world), I 
probably wouldn't want to use his system as my master.  Packages can 
always include source if they want, but you need a provides/requires 
versioning mechanism to be sure everything loaded works together.

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

Yes, but it won't get you a choice of a hundred finely tuned machines 
that do exactly what you want.

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

That's exactly the problem I want to avoid.  The base distro should be 
just enough to load the package manager and retrieve your choice of a 
package list.  Then if you don't like an existing set of packages, 
delete some, add some, and upload your new list with a description of 
why it is better than any of the others.

> And by the way, doesn't all of this smell a bit like Ubuntu in the first
> place?

No, conceptually it is the equivalent of VMWare's appliance download 
directory: http://www.vmware.com/vmtn/appliances/directory/ where there 
are hundreds of specialized virtual machine images, built because they 
are easier to copy than to build from scratch.  Except without the 
overhead of the virtual machine and with an update mechanism...

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

The problem is that it would require either new infrastructure or some 
major contortions to use existing repositories and it avoids all of the 
complications that usually create a business model.

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

There are bits and pieces that could help. One of big issues is that the 
unix/linux kernel is supposed to shield the other code from hardware 
differences and make it all portable.  However, the packaging for 
hardware related things is handled by the same mechanism as the parts 
that are supposed to be portable (except perhaps for gentoo's source 
builder) and a lot of configuration mixes hardware/local/site settings 
together.

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

Yes, most people just run windows or macs.  I don't see that as a great 
solution.

> 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 am that person. And I consider most of it a waste of time and 
something that could be automated at a much higher level. There's some 
number of 'jobs' that computers do that take a long time to set up but 
the same setup would work for anyone. Plus, of course, the mechanism I'd 
like to see would also work privately within an organization to manage 
server farms and the like.

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

That's pretty much my whole argument. The way this should get decided is 
that you should be able to offer yours as a choice if you are willing to 
share your work so they don't have to repeat it.  Then Bob or Larry 
decide for themselves if they like it.  The current equivalent is a 
massive 'howto' document describing slow and difficult steps.


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

Pre-OS X, yes, it was a closed box.

> I'll change professions before I sit again at one of those.

Are you sure you've used one since they switched to OS X and intel? Most 
of the free code base has been ported so pretty much everything 
available on Linux will work natively (I'm typing this in Thunderbird on 
an imac), plus with either VMWare or Parallels you can run virtual 
machines running Linux or windows.

-- 
   Les Mikesell
    lesmikesell at gmail.com




More information about the fedora-list mailing list