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