Re: Re: Bug#458819: ITP: nettee -- a network "tee" program
On Mon Jan 07 08 14:10, Joe Smith wrote:
> "Joel Franco" <email@example.com> wrote in message
> [🔎] 20080106020045.GA8203@netuno">news:[🔎] 20080106020045.GA8203@netuno...
>> - simplicity: like you already said, the simple command, without complex
>> pipe setups like showed in your example comments. You have to agree
>> with me that that netcat + tee pipe commands are not trivial. If I
>> had known about that commands, i will not have searched for somenthing
>> like nettee in Google.
> Good point. However, while it did take me a few minutes to cook that up,
> was still
> reasonably simple piping. The biggest trick was the '>(...)' syntax, and
> knowing the arguments to use for netcat. The rest was simple pipes and
> input/output redirection.
Exact. I didn't how to make it works, and have never seen a pipe
sequence like the yours.
> Definately not trivial, but not too terrible either. Command line plumbing
> can be much more complicated (although very complicated plumbing is
> honestly rarely ever useful).
> But you said something very important, that I somewhat hoped you would say.
> You did seach for a utility because you did not know how to do it manually.
> That there is an important advantage to a package. In particular, having
> the manpage to document things.
I'm happy that you agree. :)
>> - multiple target: you can specify multiple targets to send the stream
>> and not only one. Use the -next hostlist1(,hostlist2(,hostlist3(...)))
>> Ok.. ok.. you can make it with a complex pipe; i just can say that
>> i will say again the previous argument.
> You can indeed do that with complex piping, although it definately begins
> to get very large and hard to deal with. This is a useful advantage of such
> a package.
>> - error check in the stream data: there is a check for transmission
>> errors in the code. This is util when there are failed nodes.
> Yes it is indeed a useful benefit that definatly difficult to do with just
> tee and netcat.
>> - error handling while data is being transmited: there is a lot of
>> options to the chain not die if there is a single node failure. In
>> your pipe commands, if one node die, the full chain is lost.
> Yes, indeed. That is a real downside to chaining like that. And something
> that a dedicated program can handle much better.
> Your defense of the program here was quite good, as it does clearly show
> the benefits of such a program. A useful skill to have as a package
> maintainer. Futher, I now know to look for that utility if I ever have such
> a need. :D
I'm happy again that you approve the nettee in the Debian dist.
>> In short, simplicity and error check.
>> If you liked, can you be my sponsor? :)
> Unfortunately, I cannot, as IANADD.
Thank you by your positive words.
> To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
| Joel Franco GuzmÃ¡n .''`.
| self-powered by : :' :
| Debian Linux `. `'