[TriLUG] redhat-config-network question

Chris Hedemark chrish at trilug.org
Wed Feb 26 15:47:21 EST 2003


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

<disclaimer>Kevin, I can understand your hesitation to respond directly 
to me due to your direct relationship to my employer's account.  Just 
for the record, your personal feelings on this thread and mine don't 
reflect the business relationship between our respective employers.  
:-)  Any discussion or debate we have on this is between you & me as 
friends, as we have been friends a lot longer than we have been in any 
business relationship.  That said, whether you feel like taking on my 
points directly or not is up to you and I won't hold it against Red Hat 
either way.</disclaimer>


On Wednesday, February 26, 2003, at 03:11 PM, Kevin Sonney wrote:

> I've been looking at it since initial release Yes, it's cool, but I've
> never gotten the warm fuzzies from it. I'm not changing my stance *ANY*
> from my pre-Red Hat days.

Anything in particular about apt-rpm that bugs you?  Or just lack of 
familiarity with it?  I mean, are there any specific problems you've 
heard of to unsettle you or anything like that?

> Nowhere does it say that you have to enter valid data. You don't have 
> to
> send your system info to Red Hat. It's optional. Check the code. Run
> rhn_register and see for yourself. I think there are some assumptions
> being made here, and I'd *LIKE* to correct them if possible without
> spinning into a flame war.

Well to some extent you are being tracked.  You have a valid email 
address that everything is indexed against.  You have information about 
your currently installed packages being profiled & sent to Red Hat to 
be indexed against your personal identifier.  So while you can elect to 
not send a hardware profile, you are sending a profile of your 
installed packages and you are linking it to your personal identifier.  
Is this an accurate understanding?

> You take that risk with a magazine subscription, bank account, credit
> card, or *ANYTHING* else with your personal information on it.

Sad but true.  It's OT otherwise I would tell you about the joy of 
trying to cash my payroll checks at the bank they were drafted against 
without having an account at another bank.  Oh and to top it all off, I 
have no permanent residence.  To make a long story short, they wouldn't 
(and still haven't) cashed my checks.  I'm debating the idea of taking 
this to court rather than just getting a bank account, because I really 
don't want a bank account anymore.

> It's all
> about acceptable risk, right? I don't hear you yelling about using your
> credit card when you and I know, with a fair amount of certainty, that
> the credit card company is gathering much more intrusive data and
> records than Red Hat is.

I stopped using credit cards altogether a couple of years ago.

> With less, I might add, certainty as to how it
> will be used and by whom. Same goes for a grocery store "discount" 
> card.

*That* was opened under a fake name.

> Think on that for a bit.

Already have.  ;-)

> Anyway, it's all a choice. I'm not saying "my way or else," I'm just
> presenting an option and some reasons to use up2date.

And that's cool.  For what I do, up2date is currently the best option 
at the office.  It's far from ideal, being too much like a "Windows 
Update for Linux" than the heterogeneous package management tool that I 
really want.

> Correct. I never disputed that. But you *DO* have to trust the source 
> of
> the updates. Unless you verify GPG sigs on all packages (which I'm
> fairly sure apt-rpm does by default, right?), there's no guarontee that
> *ANY* repository is giving you valid packages.

Ummm I could be mistaken but I think up2date *is* verifying GPG sigs 
(kudos).

> Because apt4rpm wasn't mature enough at the time. It's still, by
> enterprise standards, experimental.

I wouldn't say that.  I would say that it is not, by design, an 
enterprise package management tool. It is intended for the end user of 
an individual workstation to use to manage package installation & 
dependencies.  It is not meant at all for centralized management by an 
IT organization like up2date/rhn.

> Convince the distro maintainers to
> use it, and we'll see.

Unlikely.  A totally free system would threaten RHAT's revenue stream 
from the rhn service.  Not complaining, just pointing out that RHAT's 
primary responsibility is to its shareholders *not* to the customers as 
some fool themselves into believing.

> Prove that it can do what RHN does (hundreds of
> concurrent transactions with server-side dependency resolution), and
> maybe I can get someone over here to look at it.

Honestly, if there were a Free system that did everything RHN did, Red 
Hat would be very scared of it and would have to scramble to find a new 
source of revenue to replace the doomed RHN before it starts to hurt.

Chris Hedemark
PGP/GnuPG Public Key at http://yonderway.com/chris/hedemark.gpg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+XSfdYPuF4Zq9lvYRAilcAKCoc/M3CYnYUahngTVnX8R6jL7KTwCggMPw
v6NYeVLhPVocmD99RgfUVtw=
=mvrU
-----END PGP SIGNATURE-----




More information about the TriLUG mailing list