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@xxxxxxxxx
