[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#519339: ITP: tmux -- an alternative to screen, licensed under 3-BSD

Am Thursday 12 March 2009 11:13:00 schrieb Guus Sliepen:
> On Wed, Mar 11, 2009 at 11:56:01PM +0100, Karl Ferdinand Ebert wrote:
> > * Package name    : tmux
> >   Description     : an alternative to screen, licensed under 3-BSD
> The short description should stand on its own, not reference other
> software. You can mention this package's relation with screen in the long
> description. You also should not mention its license in the long or short
> description, that's what the copyright file is for. The short description
> should probably just be "terminal multiplexer".

The short description had been "terminal multiplexer" from the first packaging 
attempts but I did not know it had to be the line in the bug report. The long 
description is extended with details from the FAQ:

* How is tmux different from GNU screen? What else does it offer?

tmux offers several advantages over screen:

- a clearly-defined client-server model: windows are independent entities 
  may be attached simultaneously to multiple sessions and viewed from multiple
  clients (terminals), as well as moved freely between sessions within the 
  tmux server;
- a consistent, well-documented command interface, with the same syntax
  whether used interactively, as a key binding, or from the shell;
- easily scriptable from the shell;
- multiple paste buffers;
- choice of vim or emacs key layouts;
- an option to limit the window size;
- a more usable status line syntax, with the ability to display the first line
  of output of a specific command;
- a cleaner, modern, easily extended, BSD-licensed codebase.

From Williams' email:
> What does this have over screen, other than being BSD licensed?

answered above.
> The design of tmux seems less secure, too.

In which way is it less secure? 
My first contact with this package was on a OpenBSD mallinglist, as I followed 
those discussions some developers where involved.
(I do not mean it is more secure by that but I appreciate their code in 



Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: