Bug#681685: RFS: homealoned/0.4.1-1
On Tue, Sep 18, 2012 at 07:53:40PM +0200, alberto fuentes wrote:
> On Tue, Sep 18, 2012 at 3:44 PM, Helmut Grohne <helmut@subdivi.de> wrote:
> > That said, I believe that the package is not being a good fit for the
> > Debian project due to its limited applicability (/24 networks only),
> > lack of documentation (change network from 192.168.1.x), but also
> > because it is serving a very specific use case. For instance instead of
> > starting tor via homealoned it might be sufficient to use a very rigid
> > packet scheduler and run tor all the time.
>
> The network is not very difficult to add and is planned as well. I
> first scratched my itch and now im turning it into a more general use
> case program.
>
> About the second part, maybe im not doing it right... i gave a little
> thought about this problem and in my experience:
> a) it does not matter how tight you set the transfer rates... it
> always had an impact in latency for me when running stuff like
> torrent. This might not be noticeable for web browsing, but it is
> important for gaming. I always had to shutdown servers when gaming.
Well I said "it might". Read "in some cases". My main point was that
there are different solutions to this problem. I just picked one that I
know works for me. In any case this just supports my claim, that
homealoned is solving a very specific use case.
> b) this is intended to run on a server like a plugserver and take care
> of the rest of the network. You cant run a packet scheduler if your
> computer is not the only one on the network.
Correct.
> c) to set up qos you have to be in control of the gateway... witch you
> might or might not be. In my case, even in some places where i could
> put myself in the middle of everything, i just dont want to pick up
> the responsibility of becoming the gateway. Aka... if my little server
> blows up, nobody else can connect to the internet because of "my"
> machine and i get a call. :). Also, qos seems over killing for a small
> lan.
I can tell that if you are sitting on the gateway outbound QoS can work
very well. So well indeed that congesting the outbound bandwidth does
not induce noticeable keyboard lag on ssh sessions. In any case this is
just an example to a different approach, not a general solution.
> d) it might be easier to run some snmp analysis against the gw or
> become the dhcpd... again... i want to avoid that for the same reason
> as c)
Well none of these are general solutions. Maybe a general solution
simply does not exist? Instead you could modularize the tool to plug in
different detection mechanisms and possibly even allow custom tests.
On the other hand you may be able to build upon an existing tool. One
tool which is able to schedule tests or checks and react to the results
is nagios. Maybe you can just write a nagios plugin, disable
notifications and provide event handlers? You would get flap detection
for free.
> This way allows me to forget completely im running the services. Its
> being working beautifully for 4 months now without touching it once :)
So in the end this really is about what value the package adds to Debian
(since carrying the package poses a cost). Until now it looks like I
could come up with an ugly hack using cron and fping that would get me
similar results as homealoned. So I believe that your package should
differentiate itself from such a hack by providing significantly more.
> Yup. I have a little TODO list full of more or less easy little tasks to do.
Maybe you could give it a bit more time and gain some feedback from
actual users (besides yourself) first?
Helmut
Reply to: