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

Re: [Sheflug] RedHat and Script Kiddies



On 24 Jan 2001 10:01:19 +0900, Stephen J. Turnbull wrote:
>     Al> Heh, don't get ahead of yourself Stephen!! I wasn't talking
>     Al> about something funky, like an rpm --rebuild
>     Al> kernel-du-jour.srpm.
> 
> I'm not, either.  I'm talking about


 (then goes on to describe what I thought he was talking about :)

Apologies if my rpm example was wrong  (I don't use rpm), but that was
exactly what I thought you were talking about:
making-binary-from-source-package type thing. What *I* was talking about
was updating-source-tree-from-source-package (i.e., missing out the
compilation bit at the end..)

> The point is that I _never_ have to deal with Debian randomness on top
> of Torvalds/Cox randomness.  If I want to, I can get the official
> source debs.  But I don't think anybody does that anymore.

I see what you mean now, yes :)


>     Al> I seem to recall having PCMCIA problems too, with potato I
>     Al> think. Works okay at the moment, although the DHCP client
>     Al> stuff seems to be screwed (i.e., it's there, it's configured,
>     Al> it don't work). I end up having to 'pump -i eth0' manually
>     Al> every time.
> 
> I think that's Hines randomness.  I think all the sensible distros
> simply throw David's shit out the window, but Debian keeps struggling
> on with it.


Hmm, no comment :)  I get the feeling something is off somewhere,
though. Having said that, it's the first time I've set my laptop up for
dhcp - static allocation works fine. I might try playing with the
different dhcp clients, it maybe a problem peculiar to a certain client
/ config combo..

 

> I don't think they should ship stock kernel binaries.  First, some of
> their "improvements" actually are, if you can afford to buy pre-setup
> from the "approved list" of hardware vendors.  (AFAIK there is no such
> thing, but some vendors will work better than others :-(. )  Others
> are popular features, with wannabes who can't compile their own
> kernels. 
> I think that's a reasonable business model: sell to those with more
> money than brains, provide source downloads for those with more brains
> than money.

Dunno. I think that they tend to end up creating more work for
themselves unwittingly though. If you're on an all-redhat network,
that's okay, but I personally don't want to have to create different
kernel builds for every single machine I maintain - I'd just rather have
the one (configurations permitting, of course). There are a number of
good reasons for running redhat on some machines (running commercial
software, such as Oracle, especially, because I've yet to see a clean
Oracle install yet), but good reasons for not running it on others. 

In a way, I think you're right, although also in a way I hope you're
not. When the Linux Distribution business starts becoming profitable
(which I hope it never does!!) I think we're going to see more
divergence. If kernels packing more in their trousers becomes a selling
point, then the competition between the distros will become
who-can-pack-most-in. Gaining market share often comes down to product
differentiation, which means divergence pretty much. If the distro
business stays borderline break-even, or even a loss leader, all the
better, because it's less competitive in terms of profit - people aren't
scrabbling over the bottom-line, they're scrabbling over brand name,
which would hopefully mean the competition is more about quality and
reputation than market share.



>     Barrie>  What is this "/usr/src/linux" madness that you mention?
> 
> Yeah, I'm curious about this, too.


glibc & other buddies (can't think of many, all development apps though)
seem to rely to a greater or lesser extent on kernel headers, which
often also live in /usr/src/linux. The idea of keeping header files in
sync with all the different versions ('specially over major versions)
doesn't fill me with glee, anyway ;)


> No, this is _not_ pointless.  This is one of the good things that
> RedHat has done.  /usr/src is on the face of it the province of the
> vendor.  In practice "friendly" admins over the years have used that
> for "official" installs of 3rd-party software to the main hierachies
> (/ and /usr).  Then /usr/local is opened up to the "trusted elite", as
> a place to share "unofficial" software.
> 
> This means that in practice the vendor should not impose special
> structure (SOURCES, BUILDS, SPECS, ...) on /usr/src.  Thus /usr/src/redhat.


I think /usr/src/redhat was definitely a stupid decision. Why upper
case? Why oh why oh why.. They could have had /usr/src/redhat/sources,
/usr/src/redhat/1specs, etc.. much nicer :)


> Depends on whether you consider them an independent business (which
> has been rather successful) or a subsidiary of Torvalds & Co, a sole
> proprietorship which has never run a profit as far as I know.  ;-)


RedHat are pretty desperate to make a profit at the moment, and I think
they'll definitely be the first 'Linux company' to do so. They've cut
back substantially a number of plans they had, I think the idea is to
very much control their outgoings.. can't blame them, really.

Cheers,

Alex.
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.