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

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

 



Hi Les,

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.


On Thu, 2007-09-20 at 08:23 -0500, Les Mikesell wrote:
> Andrew Kelly wrote:
> > 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.

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. Lot of
morphing going on, or I'm just frazzled at the end of a long week. 

Lemme see if I can recant how I followed things; apologies in advance if
I get it wrong.

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

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.

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

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


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

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

Managed distro, with support agreement. That wheel has been rolling a
long time. 
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?
And by the way, doesn't all of this smell a bit like Ubuntu in the first
place?

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

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

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

How on earth would I know what Bob or Larry might deem suitable? Good
heavens, in this list alone I see LPIC-1 level users having issues with
items I'd never think to install on my personal box. Throw an exponent
on that and you're looking at a big pile of need. It'll take more than
two and a half volunteers to master that one, Les, as I'm sure you're
well aware.

But, yes, I do hear you.

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


You know, an Apple and several fathoms of half-inch chain, and you've
got yourself a pretty passable boat anchor.

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

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

If you had such a small market share and your products were so
disproportionately overpriced and your target consumer was so ill
equipped to handle technology, I'm pretty certain you'd make every
effort to ensure that every bell rang and every whistle tooted, too.
Sheesh!

Again, though, I follow your actual point.

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

Everything is possible, Les, it's just a matter of available resources.

At any rate, I've rambled far too long and still have far too much to
do.
As I said, I'm keen to put heads together, so don't think I'm just being
combative.

Nice weekend to you, (and whomever might read this).

Andy


-- 
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux