Re: [LineControl-development] LineControl -- cvs / svn

[Stefan G. <sg...@gm...>]

Am Samstag, 11. M=E4rz 2006 09:44 schrieb S. Fuchs:
> > To be honest, I have never even looked at the monitorapplet and
> > just discovered some months ago, that it's part of klcc. I don't
> > know what it actually does or if it works at all, probably have to
> > check that ;)
>
> ok, no problem, don't hurry ;).
> what about moving to svn?

Only if the sf servers are faster than the cvs ones. As svn is atomic you=20
usually cannot CTRL-C it when things take too long, very annoying if the=20
server is stalling all the time.
I use svn myself for qlinecontrol sources, if the servers prove to be faste=
r I=20
could move sources over there.

> Hey... cool, nice to know.
> In case I write a gentoo ebuild, shall I provide the package on my
> own server or will you keep the release files at the same location
> over a long period of time?

I plan to keep the release tarballs for quite some time, the only thing I=20
usually do is purging older releases, i.e. you will only be able to downloa=
d=20
the last two releases. Otherwise we could as well try to upload files on sf=
=20
for 0.2.

> Hmm... seems I have to rewrite the linecontrol homepage. ;)

And add the "new" klcc screenies? ;)

> Btw, if you want some user feedback, then just announce your client
> on freshmeat. The feedback for the server and my clients was usually
> more or less coincident with the announcements.

I'll probably do for 0.2 then. The current release is probably a bit buggy=
=20
(read: untested) when used with more than one line, I have to configure my=
=20
server and add two emulated lines :)

> > I use linesrv2 for my 2MBit line and I'm quite happy with it. There
> > are a few things that need fixing but it works quite well most of
> > the time :)
>
> I'm running linesrv2 myself to monitor the throughput of my cable modem.
> What needs fixing in linesrv2 at your opinion? Might be good to know...

=2D close unneeded FDs when starting linesrv and when forking other process=
es

=2D safe way to monitor download/upload bytecount, simply using a long long=
=20
won't cut it (maybe a long plus another long that counts the time the real=
=20
counter would have wrapped already)

=2D sometimes my cable-modem resets, afterwards eth1 is active, from then o=
n=20
linesrv thinks the line was brought up by something else and refuses to=20
control it, that's annoying because I have to fix it with a manual "ifdown=
=20
eth1" every time

=2D web-frontend so one could even work without a client installed locally =
(does=20
linesrv have a pipe to control it?)

=2D big whish: protocol based on cleartext instead of structs, maybe use ve=
ry=20
simple xml, that would be more future-proof as clients can check if they=20
support this packet-version and don't need to know how long a certain struc=
t=20
is


Bye, Stefan aka mETz