[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:

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


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