[CLUE-Tech] Konquorer

[Jeffery C. Cann]

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

Dave is correct.

Konqueror is tightly integrated with KDE.  You would need to upgrade KDE to 
upgrade Konqueror.  The reason for the tight integration is that other 
applications (including Konqueror) use the 'web browser' features (called 
Komponents).  This is good because it enables KDE applications to utilize 
already-built components to build applications faster and they will have 
familiar look-and-feel.  On the other hand, this means that you cannot 
upgrade only some parts of KDE.

Jeff


On Friday 26 October 2001 10:10, you wrote:
> On Redhat 7.1 how can I update Konquorer without updating KDE? I can't seem
> to find a RPM for it.
>
> Thanks

- ----------------------------------------
Content-Type: text/html; name="Attachment: 1"
Content-Transfer-Encoding: quoted-printable
Content-Description: 
- ----------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjvaFzIACgkQw3/GBQk72kCeOQCglAugRjyLH4c8QAFxpg6NypP2
93sAn0Yg9r1yla828EcjatsvF2kw/Oe2
=qLkH
-----END PGP SIGNATURE-----

Received: from copper.americanisp.net (copper.americanisp.net [208.244.174.41])
	by clue.denver.co.us (8.9.3/8.9.3) with SMTP id QAA11474
	for <clue-tech at clue.denver.co.us>; Sat, 27 Oct 2001 16:13:48 -0600
Received: (qmail 31001 invoked from network); 27 Oct 2001 22:37:19 -0000
Received: from unknown (HELO sh01.shell.amisp.net) (216.38.38.12)
  by copper.americanisp.net with SMTP; 27 Oct 2001 22:37:19 -0000
Date: Sat, 27 Oct 2001 16:45:51 -0600 (MDT)
From: Brad <brad at americanisp.net>
X-X-Sender:  <brad at sh01>
To: <clue-tech at clue.denver.co.us>
Subject: Re: [CLUE-Tech] DSL QoS monitoring.
In-Reply-To: <3BD973FB.967CFFB4 at hawaii.rr.com>
Message-ID: <Pine.LNX.4.33.0110271615000.30179-100000 at sh01>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: clue-tech-admin at clue.denver.co.us
Errors-To: clue-tech-admin at clue.denver.co.us
X-BeenThere: clue-tech at clue.denver.co.us
X-Mailman-Version: 2.0beta2
Precedence: bulk
Reply-To: clue-tech at clue.denver.co.us
List-Id: CLUE technical discussions, questions and answers. <clue-tech.clue.denver.co.us>

Inline-

On Fri, 26 Oct 2001, Cyberclops wrote:

> I can't speak to your problem, but there have been a lot of similar problems
> with TechAngle's service lately.  They say it is the phone company's fault.  I
> can't say.  Sometimes I do believe it is the phone company and other times it
> seems more like a glitch in the TechAngle service.  Whatever the cause, it's
> the weak link in the Linux operating system.  I use Libranet Linux (Debian) and
> it's absolutely a solid performer, but I can't say the same for the ISP
> services associated with Linux.
>
> B O'Fallon wrote:
>
> > Dan Harris wrote:
> >
> > > I used to use AmericanISP also
> >
> > About a month ago, I switched from AmericanISP to PCIsys. I had been a
> > customer of AmericanISP for almost 18 months.
> >
> > At random intervals their service would go down. When I first started using
> > them, this happened perhaps once a month, once for two days, but more
> > recently might be for just a couple of hours every other month.
> >
> > The reason I finally left was because I could not connect to them between
> > 0500 - 0800 each morning. I use DSL and if I left the system on overnight,
> > and the connection was not broken, I had no problems with getting my mail
> > and browsing. But if the connection got broken (and it got broken a lot --
> > just about every day), I could not connect at all. It was like they were
> > non-existant.

Hmm.  About a month ago- we found a cleanup script which
caused this problem for some of our customers- where they
could not connect early in the mornings.  It has been
fixed since.

> > Now they swore up and down that I was not connecting, and that the problem
> > was with Qwest's DSL service. And, of course, Qwest swore up and down that
> > it was AmericanISP's problem. Qwest's line checks showed that I was
> > connecting to AmericanISP at that time, but it was like they were ignoring
> > me: I would get "Hostname not found" and pings would come back timed out.

We have been documenting many cases where Qwest's Interprise
ATM DSL network causes this problem.  Qwest will always
swear it is the ISPs problem if the customer can 'train' to
the Central Office hardware- no matter what the problem
really is.

In *every* case, we have to get a 3-way conference call
going with the customer, us, and Qwest- just to proove to
qwest that their ATM network sucks (and eventaully open a
interprise trouble ticket for resolution).

Our diagnostic abilities are limited to a few critical
facts-
Does the user hit a DSL gateway on our facility?
Does the user hit our RADIUS authentication server?

In all of these cases, the answers to the above questions
are both 'no'.  Qwest was simply not delivering the data to
our facility.  The user will show the line being trained,
but will not be able to authenticate or ping anything.
Qwest will say it it our fault because the customer's line
trains.  The process takes a minimum of three hours per
subscriber to diagnose with qwest's help.
Fortunately, Qwest only breaks about 2% of our customers.
Still enough to file weekly PUC complaints though.

> > So while they swore up and down, I just swore. I finally got tired of not
> > being able to get my morning dose of Slashdot until 0830 or 0900, and having
> > to rearrange my schedule for the rest of the day, so I dropped them.
> >
> > To this day, I still think that they had a block out period on me. This
> > problem never occurred at any other time of the day. Of course, they said
> > that they didn't, but it seemed suspicious that it could have been anything
> > else.

I apologize for the cleanup script problem.  If we had found
it when you were still a customer, we would have given you
downtime credit.

You see- (I can actually explain the process to technical
people) Our customer data is stored in a MySQL database.
This database is constantly queried to generate
configuration files, password files, DNS zone files, etc,
etc... Just about everyting right down to Cisco RSP VLAN
configuration for colocation customers and hand geometry
backup data for hand readers in our facility.
The cleanup script that kept you from connecting had a flaw
with it.  When the database went down in those morning hours
for backup and self-check, the script was not aware of this,
and overwrote a config file ommiting SQL gathered info.  It
now properly checks for these things, and everything works
great in that department.  I assure you, we had no
block-outs on you or any of our other customers.  Filtering
or blocking any of our customers or their content strongly
violates our policies.

> > I have (not yet) had this problem with PCIsys. I can connect at any time,
> > just like a real ISP.
> >
> > But I never noticed any problem with slowdown in their connections. My
> > downloads were usually about the same speed as with PCIsys.

We do not put any download restrictions on our clients.
Qwest will set the train-rate for the line, and we will pass
whatever they can push through that ATM network.

> > BOF

Thanks,
Brad Baker
Director: Network Operations
American ISP
brad at americanisp.net
+1 303 984 5700 x12
http://www.americanisp.net/