Hacker News new | comments | show | ask | jobs | submit login
Tmux 2.0 released (sourceforge.net)
353 points by byaruhaf 1017 days ago | hide | past | web | favorite | 216 comments



It makes me sad to see a respectable piece of open source software hosted on this site with its intrusive advertising practices such as ads with fake "install" buttons on the download page.

What is the advantage of using Sourceforge these days when github and bitbucket are free for open source?


Even before github was around, sourceforge was a PITA. I remember clicking through the web UI for more than half an hour before finding the place where you could configure the project website/homepage.

Also, trying to delete an abandoned project, which had a mailing list, but it wouldn't let me delete the mailing list, because there was still an admin in there (me!), and I couldn't leave the mailing list, because then it would have been without admin. D'uh. And you couldn't delete a project with an active mailing list...

Then a few years later, after I didn't use SF much anymore, I tried to comment on the bug in the bug tracker, and didn't find any option to do that, even as a logged-in user.

I used google code as soon as it became available, because it worked, and had a much cleaner admin interface. Not to mention user interface.


> What is the advantage of using Sourceforge these days when github and bitbucket are free for open source?

I imagine the author figures that moving is a pain.

Don't forget, Sourceforge was the Github of yesteryear. I imagine in 10 years we may very well be asking the same of some old project hosted on Github.


Sourceforge's downfall was not finding a better business model than advertising – which has devolved into the worst kind of spammy ads. GitHub, on the other hand, has a solid business model that doesn't involve advertising. In fact, putting ads on the site would be suicide.


Sure, but you can't say with certainty that Github's fortunes won't change X years down the line is my point.


That’s true, but the risks are significantly diminished. As they say, your business model is your destiny, and if have a good business model...


Sourceforge tried to find a better business model -- sourceforge enterprise edition -- but then spun it off and then sold it to a different company (CollabNet) in 2007...then over the next 3-5 years, laid off almost everyone behind sourceforge.net/OSDN. The only thing left of the company now is thinkgeek.


> Don't forget, Sourceforge was the Github of yesteryear.

Not really.

At that time, there were almost no alternatives. Sourceforge was slow and bloated, even without ads. Nobody wanted to use it, but at least it was free (in the sense of free beer).

And it took them ages to support SVN in addition to CVS. When they finally supported it, many project were already thinking about switching from SVN to a distributed VCS.


> Not really.

How do you figure? It was "the way" to share your OSS project in its time. It wasn't great, but it was the best we had.


> It was "the way" to share your OSS project in its time

Nobody questions that.

But that doesn't quality for "the GitHub of that time", because most people like to use GitHub, so the analogy is incomplete in some essential aspects.


Eh, that's pretty nebulous. There's a whole lot not to like about GitHub, too. Vaguely hand wavy "oh that doesn't count cuz most people like GitHub" isn't really much proof of anything.


If you had the resources to host your own tracker/repository/wiki/mailinglist instead of using Sourceforge you did that. Github is so good it's actually hard to convince people it would be a good idea to have server for those things, even if money and time isn't the issue.


Not sure what you mean by "proof". Just take it as an anecdote of a contemporary witness. From your previous comments it seems that you didn't have to suffer through that time. Lucky you!


Hah, not quite. I've been in IT since 1995, suffered a layoff in the first dotcom crash. Don't get me wrong, Sourceforge has never been something I liked, but that didn't mean I agreed with the premise.


I'm also struggling to see any advantages to still using Sourceforge in 2015.

Firstly, they're well-known by now to be complicit in sponsored 'wrapper' installers bundling some pretty awful stuff - check out what they did with FileZilla - which is an even more intrusive advertising practice than that.

Secondly, they host a lot of executable code (and don't forget build scripts in source code, unless you check your Makefiles!), but they still don't use TLS, and don't even seem to have any plans to - which is by now negligent practice, I think, considering the widespread public knowledge of Hacking Team's (and GCHQ's) at-scale deployments of network-level file infectors.


SourceForge itself is free software. I think that's one possible reason to use it rather than GitHub or else. The other possible is that SourceForge provide mailing list server and other service for projects. Anyway, you won't move a project around unless you have some strong motivations.


Is SourceForge really open source? Guess I must have missed that news. Regardless, Gitlab would still be a better choice in terms of UX and is also open source.


It has been released as Apache Allura, Wikipedia has a nice overview: http://en.wikipedia.org/wiki/Apache_Allura

Install docs: https://forge-allura.apache.org/docs/getting_started/install...

I agree that sourceforge.net as a service might not be my favourite, but Allura the forge-software seems pretty good. I think the only thing that comes close is the stack from Canonical -- but Allura seems more viable to self-host (and scale up when needed -- rather than "only a vm" or "full cluster"). It also seems less "overly opinionated", and still includes sensible defaults (contrast with getting up and running with Trac).

YMMV, but it doesn't look half-bad. Right now I don't need anything more than what you can easily get with either a separate wiki+mercurial+mailing-list, "just" trac or fossil -- but for something in-between "too big to host internally" and "too complex for Trac to be easy" -- it looks rather interesting. I'd love to hear any war stories.



Do you know if Gitlab allows attachments in bugs and comments? It's one of the major deficiencies in Github.


GitLab developer here; it does! Where GitHub only allows images to be dragged into issue and comment description fields, GitLab allows this for any type of file.


Thanks! That's great. I'll use Gitlab going forward :)


Not having to move is a major plus.


Ditto. I more or less refuse to use Sourceforge.

There's an up to date clone on GitHub at https://github.com/ThomasAdam/tmux

Can't send patches to it, but it's great if you're just building it.


That's right, you can't send me patches as they're to be sent to the tmux mailing list. Is this not made clear already in the repository description?


I don't think GP was criticizing, just making a note of it.


Github isn't completely open-source. Source: http://tom.preston-werner.com/2011/11/22/open-source-everyth...


Or, they could go one step further and do it like WinSCP.

That is, WinSCP has an own website that contains ads with fake download buttons. It's really nasty, but at least the advertisement payments go directly to the project, rather than just to the hosting service.


I was thinking exactly this, I just logged a bug for them to move the project: https://sourceforge.net/p/tmux/tickets/192/


Aaaaaaaaaaaaand it's closed. Without comment.


Searching the tmux mailing list [0], it looks like there were some recent discussions about migrating to GitHub.

Basically, it looks like the developers don't see any benefit to migrating that outweighs the cost of a migration. [1]

There is a GitHub mirror [2] maintained by, I think, one of the developers, but they don't accept pull requests.

It's interesting to note that, for such a popular project like tmux, there are so few contributors. [3] Five, to be exact.

Maybe that's an artifact of how the mirroring to GitHub works (perhaps the commit authors aren't translated correctly?), but I suspect it's more an artifact of an outdated contribution process and tooling.

[0] http://sourceforge.net/p/tmux/mailman/search/?q=github

[1] http://sourceforge.net/p/tmux/mailman/message/33826395/

[2] https://github.com/ThomasAdam/tmux

[3] https://github.com/ThomasAdam/tmux/graphs/contributors


lots of people have contributed to tmux (on a quick grep through the logs, probably ~25 have made significant or multiple contributions, ~170 have made small contributions)


Hi Nicholas! That's good to hear, and definitely makes more sense given how popular and old tmux is as a project.

So I guess something just didn't translate correctly to Thomas's GitHub mirror.


All I see after clicking download is a direct link to the file, which is in fact just a .tar.gz.


Are you sure you don't have any ad blocker installed?


A reasonable followup question why wouldn't one have an ad blocker installed?


Because it's how 99% of websites get their funding, allowing them to survive. Why have an adblocker installed when you can avoid the sites with obnoxious adverts?


Sometimes I have to get useful tools from them....like tmux.

As to why I use Adblock, I've never. Not once. Ever. Bought anything from an ad on a website. I _have_ bought books and such from the referral links on blogs (which adblock doesn't block).

The reason I use adblock is because I'm not the demographic ads on websites are targeting. So websites aren't losing any revenue by me not seeing their ads.


Of course they lose revenue. your view is like any other. (http://en.wikipedia.org/wiki/Cost_per_impression) you won't be taking money from the company, which started the ad campaign. also: don't underestimate the effects on brand value, which will come subconsciously, if you look at ads. You will know certain companies are still active etc. This is why you don't necessarily need to be targeted. simply informed.

The "sometimes" you talk about should just be with ads on. it won't hurt much, because it's just sometimes.


> don't underestimate the effects on brand value, which will come subconsciously, if you look at ads.

This is exactly why I use adblock.


Only if you view CPI in isolation as money from the sky.

Marketers estimate the CPI they're willing to pay based on estimated conversions per impression. Ultimately, the money comes from sales. It always comes from sales.

If I don't ever purchase anything from a website ad, my impressions are worth zero. My impressions, and impressions by those like me, will drive down the price a company is willing to pay per impression since the conversion ratio also goes down. In fact, my impressions incur a negative effect since it still incurs a cost to the advertiser.

In the best of all possible worlds, only those who will ultimately buy a product are displayed the ad. Resulting in a 100% conversion ratio. Each impression would be maximally valuable and the price paid for that impression would rise to reflect that.

Those of us who use adblock have removed ourself from the market and from the conversion ratio calculations and cost per impression to the advertiser.


They might lose revenue at first, but in a way that is entirely healthy for a larger system of advertisers and clients, in that both advertiser and client reassess the effectiveness of an instrument (an ad network or product), and thus reassess the correctness of a price for an advertising opportunity.

Maybe I'm apathetic to these arguments because I'm quite comfortable paying for content and services, and I'm comfortable with a version of the web where a paying class gets to have paying-class products. If the public feels there should be a free thing, then let it be funded by taxes.


That's now how ads always work. Many sites get revenue based on impressions, not clicks or conversions.


Websites absolutely do lose money when you block their ads. Regardless of what one chooses to do, you should be aware of the facts.



Adverts are not just about getting a click to follow through to a purchase.

What do you gain by blocking adverts? An extra 150K from your data plan?

>websites aren't losing any revenue by me not seeing their ads.

This argument is a little too close to justifying piracy for my liking. "I wasn't going to buy it anyway, so it's fine"


What do you gain by blocking adverts? An extra 150K from your data plan?

Quicker page loads, avoiding seizure inducing ads that are designed to attract your attention in an overly aggressive way, better visibility of text because it's not surrounded by flashy pictures, animations and videos. Plus avoiding Flash/Java/JS ads poisoned with malicious content.

And, oh yeah, and ~150K that won't hit my data plan.

For the record, I don't block all ads. I have sites that I allow them on because I am a frequent user and their ads are not too obnoxious to deal with. If my page views (never clicks though) help them then great! But I surf with the blocker on by default for the reasons laid out above.


> What do you gain by blocking adverts?

...a lack of adverts?

> This argument is a little too close to justifying piracy for my liking.

Except it's within everyone's rights to decide how their computers will render a given piece of markup.


> This argument is a little too close to justifying piracy for my liking. "I wasn't going to buy it anyway, so it's fine"

Do you also think not buying a Toyota is a little too close to car theft?


Consuming content or a product whilst deliberately evading the means put in place to compensate a creator for the work done is akin to piracy. I don't see how there's any question that that isn't at least a morally grey area


"Your contract with the network is, you're going to watch the spots. Any time you skip a commercial or watch the button you're actually stealing the programming."


Because the venn diagram of "obnoxious adverts" and "adverts" is nearly a perfect circle.


>Because it's how 99% of websites get their funding, allowing them to survive.

So then, I'll unblock ads to help companies survive just as soon as those companies start giving me money to help me survive.


If you don't value what the website is giving you, why are you visiting it?


Curious, if I visit the site in question using lynx/links am I still in the wrong?


At least with lynx/links, you don't get any javascript functionality and the experience as a whole is diminished.

With an ad blocker, you selectively block the javascript you don't like but that the operators rely on to bring in revenue, while still getting the otherwise 'full' experience.


If sourceforge went under, do you think I'd be unable to get the source to tmux?

Since obviously I'd still be able to get tmux, what value is sourceforge actually providing me? They might be providing tmux developers some value, but they aren't providing any value to me.


I value what these sites are giving me, but not enough to put up with ads. If adblock didn't exist I'd probably visit places like sf or youtube a lot less.


Advertisers had their chance to not suck, but they blew it. Sorry.


If you're developing anything for the web that might involve advertising, and even certain things that don't, it makes it hard to test, especially if you continually forget to disable your ad blocker. (I'm only being marginally facetious; I worked with a developer who refused to accept that his ad blocker prevented him from seeing issues with Omniture - now Site Catalyst - eating mouse clicks.)


The original question was, why use a host that tries to show you ads in the first place?


Because I don't want my user agent to be modifying documents I'm requesting.


That is actually a rather unreasonable question. It's like telling Firefox users to install chrome.

Or that ponzu schemes are okay as long as you yourself don't have to deal with them.


A ponzu scheme is a fraudulent investment operation where the operator pays returns to its investors from citrus-flavoured soy sauce sent to the operators by new investors.


If you try to curl that "direct" link, you'll find it isn't.


Perhaps no advantage, but it's a good thing. As in the CPU market, there are Intel, AMD, even another architecture alternatives, eg. ARM. It's just an analogy. :-)


Does anyone who would be downloading tmux not use an ad blocker? Because if so, consider me shocked. I mean, not that the ads aren't still a moral concern, but from a practical standpoint it doesn't seem like a big deal. I didn't even realize Sourceforge still had ads...


For those who are just getting started with tmux: I advise looking around others' .tmux.conf files for some sensible settings. Like Vim, Tmux ships with a lot of powerful features disabled by default.

My absolute favorite has to be binding a hotkey to opening URLs in the current window [0]. See [1] for a small demo I just recorded.

To get started, here's my current config: [1]

[0]: https://github.com/jbnicolai/tmux/blob/master/.tmux.conf#L12...

[1]: http://recordit.co/vdxy09GpYG

[2]: https://github.com/jbnicolai/tmux/blob/master/.tmux.conf


I wrote a book titled "Getting started with tmux" which can be a helpful guide for those who may want to get started.

http://gettingstartedwithtmux.com

(Sorry if the self plug is not cool, I'm happy to delete this comment if it's not ok but I figure the community may get use out of my work)


As long as the comment is useful and contributes, I think it's fair game. This definitely qualifies. That said, if it's not free, I personally would prefer that be mentioned, (and at the same time a link to a free sample chapter or equivalent if it exists would be useful).


90% of HackerNews is self plug ... so don't worry :)


It was quite a good book! It might be due for an update, what with tmux plugins and other new tools. I'd buy an updated version.


Thanks! It was most helpfull when I got to know tmux.


Here's mine: https://github.com/olalonde/dotfiles/blob/master/tmux.conf

One tweak I can't live without is having the same key bindings to seamlessly switch between tmux panes and Vim split windows. (https://gist.github.com/mislav/5189704)

TPM is also really useful for managing tmux plugins https://github.com/tmux-plugins/tpm.

My prefix key is Ctrl-Space. It's very convenient to press on the keyboard, I'm surprised to not see it used more widely (maybe because it's commonly bound to some OS utilities?).


> One tweak I can't live without is having the same key bindings to seamlessly switch between tmux panes and Vim split windows.

YES, THIS! Setting up directional pane navigation to work with both tmux and vim panes as first-class entities was a huge workflow boon for me as well. It was a significant change that helped kick my setup over into vim+tmux+zsh as IDE vs. merely a collection of separate parts.

It's worth noting that some relevant bits of @mislav's stuff has been packaged up nicely as a Vim plugin:

https://github.com/christoomey/vim-tmux-navigator

I also just noted that @tarruda (of neovim fame) chimed in on @mislav's gist with his own independently created version of the Vim-side of things. It looks worth comparing some of the implementation details from @tarruda's work, he's done some stuff to eliminate redraws in Vim, etc.


> It was a significant change that helped kick my setup over into vim+tmux+zsh as IDE vs. merely a collection of separate parts.

Same thing here :) I also set `tmux attach -t base || tmux new -s base` as my start command in iTerm which kind of forces me to use tmux windows/panes/sessions instead of iTerm tabs. It took a while to lose the habit of hitting `cmd-t` but was definitely worth it.

The thing that sucks now is that I'm really not sure which parts of my environment can be optimised further other than learning new Vim commands :)


Heh, I have something similar, with a tmux session-start script[1] that's the first thing run by my default iTerm windows. It displays and lets me select from existing sessions via prompt tab completion. Or I can just enter a new session name at the prompt.

In iTerm, this would be a start command of:

    login -fp YOUR_USERNAME /Path/To/local/bin/mux --prompt
Or used directly from a normal command line (with zsh completion [2]) as:

    mux <session_name>
Apologies to tmuxinator users for conflicting with 'mux'; obviously feel free to rename it. This is really just a part of my personal setup vs. a formally published utility, and I don't use tmuxinator.

[1] https://github.com/jwhitley/tilde-local/blob/master/local/bi...

[2] https://github.com/jwhitley/zshrc/blob/master/.zfunctions/_m...


Honest question: Is there any benefit of using tmux over a proper tiling window manager? Or, why would I want to delegate some of the window manager tasks to a terminal emulator?


I use both a tiling window manager (xmonad) and tmux. The main reason I started using tmux was to do pair programming sharing the same terminal via ssh. If you pair program and have never tried this before, I highly recommend trying it. I live in Japan and even pair with people in London using tmux and vim. It's the next best thing to being there.

After I started getting used to using tmux, I found that my workflow naturally separated between things I'm doing on my terminal and things that require X (like my browser). These days I use a separate workspace for X apps and terminal (occasionally moving them around).

To make my life easy, I've added xmonad-like key bindings and window layout to tmux. Since other people are sharing:

https://github.com/ygt-mikekchar/dotfiles/blob/taka/home/.tm...

I often work while travelling and when I'm on the road I often don't bother cranking up X -- just work in the Linux console. Using tmux I barely notice a difference in my workflow and it helps extend the battery.


For me it's having two different terminals connected to same tmux session. I use tiling window manager and work on two monitors. Sometimes there is some stuff that I'm working on on my main monitor but I want to have quick look at the terminal. Because I have two terminals opened on both monitors I can just switch to the other one, press ctrl+f(my prefix)+number and have exactly same window as in my main terminal.

For anyone wondering you can achieve above by typing tmux new-session -t and giving it number/name of your current session.

Also there are minor things that are nice. Like if you need to open another terminal instance in the same directory as you're currently in.


Yes, there's lots of value to tmux outside of "window management", even if you only use it locally. That said, lots of the value is using it remotely.


I use <C-s> myself, but <C-Space> works just as well I suppose. Not bound to any OS utilities on OS X afaict.

Thank you so much for pointing me towards that vim+tmux gist!


I use <C-s> for my local machine, and I make the servers I login to use <C-a>. I bind the caps-lock key to ctrl, so it works out pretty well, and lets me work with both local and remote contexts at the same time fairly nicely.


C-Space sets the mark in emacs, which is a regularly used operation.


> My absolute favorite has to be binding a hotkey to opening URLs in the current window.

I suppose this stops working if you SSH into some box and run tmux there? I've implemented something similar, but as an urxvt plugin instead, which avoids that limitation: http://www.cs.helsinki.fi/u/tmtynkky/urxvt.png (Once Alt-O is pressed, the hotkeys with the red background appear next to each link; pressing the hotkey opens the link in browser and copying to clipboard is also possible)


You're absolutely correct, although I do all my terminal work locally in tmux as well (and often nest any remote work in a secondary remote session).

Liking the plugin you wrote!


Why do you create a new window to maximize a pane [1] instead of using resize-pane -Z (mapped to bind-key z by default)?

[1]: https://github.com/jbnicolai/tmux/blob/master/.tmux.conf#L96


Because <Leader-Z> didn't exist in the latest version of tmux at the time. I've removed it now though, thanks!


> Like Vim, Tmux ships with a lot of powerful features disabled by default.

lol, my tmux keys are basically model after vim. This is the book I used to learn tmux and has vim key settings:

https://pragprog.com/book/bhtmux/tmux


Thanks for reading.


Zoom/Unzoom is now part of default tmux.

<bind>z

So you can remove this line from your config:

https://github.com/jbnicolai/tmux/blob/master/.tmux.conf#L98


You're absolutely right, thank you!


You use ctl+s as your bind?


I use ctrl+s on my local config and I use ctrl+a on my remote tmux.conf's.

That way I can attach to a remote tmux in a local session and not produce a terminal muxing singularity that swallows worlds.


I made the mistake of having the same hotkey once. I can verify the existence of said singularity.


Using ` as my bind (no modifier) has been the best thing that's ever happened to my productivity in tmux.


I do the same, and also set up many ` commands to work the same way in emacs.


Consider using <C-Space>. I recently switched and it's made a world of difference to my speed.


Even faster, I set my prefix to just Caps-Lock. See https://github.com/mifix/dotfiles/blob/master/tmux.conf#L5


Amen. This, plus remapping Caps Lock to Ctrl on my Macbook Air was a life changer :)


FWIW, I spent some time deciding what to use years ago and decided on <C-j>. No complaints, and <C-s> feels awkward to me trying it now.


I do. It's closer to the prefix/leader I was used to when using screen (<C-a>), and I find it easier to type.


Ahhhh. Maybe I'll switch from <C-a> to <C-s>, I still miss using <C-a> in Vim to increment integers!


Exactly! And don't forget about <C-a> to move your cursor to the start-of-line in your terminal.


Why not use C-a?


I also use C-s on my local machine because:

1. I can still use C-a with readline (go to first character)

2. If I ssh and then use screen, I can use C-a to navigate my remote screen and C-s to navigate my local tmux.

3. C-s is closer to C-a then other letters on my keyboard.


C-a still works with readline. You just need to C-a first to 'escape' tmux and then C-a again. Actually just hold ctrl and hit 'a' twice.

C-s will suspend the terminal on some platforms. (Which can be resumed by C-q.)


Because C-a already does something useful.


I assume ctrl-s is easier to press than ctrl-a, I have trouble with ctrl-a on Mac with reconfigured CapsLock, and my bind key is ctrl-space.


That's why I remap the right alt key on mac (laptops) to ctrl. Having left right balanced ctrl keys is much more important for my workflow.


For a while I ran a setup where I did all of my work in a local tmux session, but part of this work involved SSH-ing and attaching to a screen session.

When using both, especially nested, I found it beneficial to have a different leader for each.

I also use <^-a> to go to the start of the line, so I'd miss that.


I use `bind a send-prefix` and do a `<^-a> a` to make up for the bind :)


Ctl+s is particularly nice if you've remapped CapsLock to Ctl.


Love your shell prompt. Mind posting your .zshrc/.bashrc?


Nevermind, looks like you are using powerline, found it, got it. :)


Does anyone else wish tmux were modal like vim, ie. without a "leader" key? My conf file has a ton of custom key bindings for window / pane management, and I'd love for them to go away or become simplified by simply dropping into a "window management mode". Likewise, I'd like the command mode to stay open until I close it. I have some scripted hacks to do this, but it's nowhere near what I'd expect from true modality.

One of these days I guess I could get around to writing a patch. This single feature is probably my most wanted for any software at the moment.


Yes! Probably my biggest workflow pipe dream since getting some fluency in vim is to be able to drop into an "outside mode". I've cobbled something vaguely modal together for bspwm with abuse of shkd, so a lot of the binds map similarly, but like your solution it's far from ideal.

As for "Why would you want this?" For me, the straightforward answer is "modes are modular". A core concept in vim is that your input can be thought of as a string describing the edit you wish to make, and modes help me keep that manageable in my head: I can first think about the mode I plan to enter, and then separately what I plan to do under the constraints of that mode. It's a little hard to explain, and I'm sure acolytes of other paradigms have their own philosophies, but it fits in really well to my workflow.

It's a subtle thing in the limited world of text editing, but I definitely miss the semantics whenever I leave it, whether to a terminal or a browser or whatever. So for me, it comes down to wanting to bring the cost of task switching closer to what it is in the editor.


"It's a little hard to explain, and I'm sure acolytes of other paradigms have their own philosophies"

Yes, yes they do[1]. Some people (not me) are vehemently, religiously opposed to "modes":

"To promote his preference, as of 2010, Tesler equipped his Subaru automobile with a personalized California license plate with the license number "NO MODES". Along with others, he has also been using the phrase "Don't Mode Me In" for years, as a rally cry to eliminate or reduce modes."

[1] http://en.wikipedia.org/wiki/Larry_Tesler


Maybe because I'm an emacs user, I find it pretty intuitive. As a ratpoison/conkeror/emacs/tmux user I often find myself juggling at least 4 sets of prefix keys. It works surprisingly well, I just made sure they are in different places on the keyboard, so that I don't mix them up.


Odd. I'd consider myself a 'power user', but I hardly ever find I have that need. Could you describe what you do when you're entering several command-mode lines in succession?


it would probably be a relatively easy change to make this happen with key tables (which are in git), you would only need to change it so there is a way to permanently enter a key table (at the moment the key table is only entered until a command is run from it)


I recently discovered Tmux after years of using GNU Screen. I love it. It feels much easier to use and more intuitive, easier to script. Also integration with terminal emulators such as iTerm2 on OS X or Byobu on Linux is fantastic. Tmux earned a place in my list of favorite daily used tools.


The biggest advantage of tmux over screen is its ability to automatically resize based on the smaller terminal connected to it. I know there are a lot other advantages, but this in itself was a game changer for me.


I use tmux all the time, but I've read about dtach/dvtm.

http://www.brain-dump.org/projects/dvtm/#why

Anyone using that instead ?


I use dtach because detaching from the terminal is the only feature I would use in tmux.


That was one argument I saw on an article, dvtm carries a simpler self-sufficient task and is far smaller than tmux. Separation of concerns etc.


I'm using dvtm, after trying screen and tmux in the past. No particular reason other than it's Xmonad-like layout switching.

It's crashed once, in a few months of usage. Make of that what you will.


Hmm, make that twice. Maybe I'll go back to tmux ;)


Have a look at abduco as well. It's a (IMHO) more user-friendly (and supposedly cleaner) dtach replacement, from the author of dvtm.


Congrats to the Tmux team for a great open source tool. Its sad that HN decided to take this moment to talk about sourceforge and not the product announcement.


Yes, I'm also a huge fan! I'm sorry for the derailment. I probably should have put it in a separate post.


It's a tool I use daily, I love Tmux!


Why should I use tmux over screen?

Why do I use screen over tmux?:

- its old. A stable version is on every distro. Trying to start a screen session is more likely to succeed on any given box than a tmux session. I see my friends wrestle with their tmux setup being more recent on one box than another and their nested sessions get screwed up. I never have any issue.

- I know it, and for my simple use it does everything perfectly. I can split panes, I can detach and come back, I can nest sessions.

- screen can attach to serial terminals.

What's the killer feature of tmux that I'm missing out on?


Not sure if it works in GNU Screen but tmux can be controlled from the command line. Examples:

    tmux show-buffer | vipe | bash -
    tmux send-keys -t debugger run
This allows nice ad hoc scripts that are composable in a very Unix-y way.


It's maintainable, modern code, which screen is not. Screen is not dead yet, but it eventually will be.


He didn't ask which one is nicer to hack on.


No, they asked "Why should I use tmux over screen?", which the answer was relevant to.


Doesn't seem that way to me at all.


I use both, and enjoy that they have different control keys by default, so I can nest them painlessly without need for any configuration.

Also, tmux works out-of-the-box for accounts that you su'ed into, something I never managed with screen.


Try out Byobu. It's built on tmux, and it's nicer to use than screen, I find. Stupid name, but has some conveniences. Mostly I just use F2 to create a parallel terminal and F3/4 to cycle through them.


Does tmux still have no flow control? Just compare how tmux locks up when you `tar xfv linux-4.0.tar.xz` and screen doesn't. None of the knobs to control output throttling helped. How do you get around this problem?


I run `stty -ixon -ixoff` once and that fixes the issue for me.


That's a different flow control than what I'm talking about. tmux is just overwhelmed and cannot keep up with the output from tar whereas screen takes care of it and still responds to user input. Frankly I'm amazed there's only one or two posts about this on the internet as there's more than the pathological linux tarball extract where this problem will lock up tmux.


yes, this sucks but i have never myself been able to find a reliable case where screen reacts any better than tmux (for example, both behave similarly with yes(1))

the c0-* stuff is poor (i'm tempted to remove it) but it is not an easy problem to solve, people want tmux to be fast, except when they don't. it's also tricky remotely where ssh and the network stack are buffering too


The main thing that I wish I could have in tmux is the ability to disable other sessions attached to the current terminal without outright detaching them. I intend to go back to that other machine at some point, I just don't want its tiny screen making my current session tiny for no reason.

Maybe this is actually possible already and I just haven't found it?


Say you want to attach to session 0 (use `tmux list-sessions` to see available sessions).

A trick I've found is not attaching to that session, but starting a new session sharing all underlying windows. The model in tmux is [session]->[windows]->[panes], but something I did not realize until recently is that [session] can be multiple.

So rather than `tmux attach -t 0` use `tmux new-session -t 0`, allowing you to interact with the same windows without disturbing the other session.


Is this a feature in 2.0? It doesn't seem to work for me - I still see a large part of my terminal window filled with the dots, since the other session's terminal window is much smaller.


Ah, I forgot to mention: the resize -if the terminal-window is smaller- will still happen, but as long as the two sessions are operating on a different window they can be of different size.


I think I'm missing something.

Terminal A: 300x10 lines (long across, but short) Terminal B: 120x30 lines (standard new terminal size)

I have a tmux session running in A; I open terminal B, and attach to it with -new-session. My first pane is trimmed to the height of Terminal A.

If I do prefix-c (create new pane), the new pane is now the size of Terminal B - hurray!

But if I open Terminal C, which is yet another size, and attach to my existing session, it resizes every pane in Terminal B to the size of Terminal C; and when I disconnect from Terminal C, those panes do not appear to switch back to what they now should be, unconstrained by Terminal C.

(If I didn't explain this clearly, I can provide some screenshots later.)


> But if I open Terminal C, which is yet another size, and attach to my existing session [...]

I might be misunderstanding, but could you not use `tmux new-session -t 0` again for the third terminal?

> and when I disconnect from Terminal C, those panes do not appear to switch back to what they now should be, unconstrained by Terminal C.

Odd. Unrelated to your earlier issue, but that's not what I'd expect or am seeing when I try to reproduce is locally.


you need to turn on aggressive resizing.


Aha, thanks!

(Also, good to see you again, digitally - how's your hemisphere?)


Pretty good; working from a co-working space here. Just bought an apartment.


I don't have any issue with the session itself being shared. It's actually the desired behaviour almost all the time. I just don't want to be dependent on the frame sizing of a terminal no one's even looking at.


jbnicolai's method kinda solves this for me. The upshot is the set of windows is mirrored between both clients, but they can each be looking at different windows. You still have a problem if the other client is looking at the same window that you're on, though.


Would doing <bind>D (note the casing) help? It will list all the currently attached sessions and allow you to remotely disconnect them. I use it when I forget to detach at home and I'm at work or vice versa.


That's exactly what I do. First of all, it's annoying that I have to go and choose each one to detach it. Second, I usually invoke tmux directly with mosh or ssh -t, so detaching also disconnects them, which I don't really want.

I basically want an untouched session to go into a screensaver mode where it no longer controls the terminal size.

It's certainly not the end of the world to detach them, but I'd rather not. And detaching before I leave a session is just busywork.


Just send it to a different session then switch back when you're ready.


Could you explain in more detail? I don't understand the practical meaning of what you're suggesting.


I've only recently discovered tmux (feels ashamed).

It's fantastic. The only thing I miss is just a sprinkle of mouse interaction. Moving around with the keys is easy enough of course but if you have a terminal in an otherwise desktop environment, it would be really nice to just be able to "click" in a pane to focus it.


Put "mouse-select-pane on" in .tmux.conf.

If you check the tmux manpage and search for 'mouse', there's a whole bunch of mouse-enabling options; you might as well turn them all on -- except for "mouse-utf8", which is a compatibility option that can potentially screw things up.

The downside to enabling mouse support in tmux is that it disables mouse support in the outer terminal (the one tmux is running inside). If you select text in tmux, it will go to the tmux clipboard instead of your system clipboard. You can get around that by holding shift before selecting text, but some people get annoyed by the extra action required.


Try these options:

  set-option -g mode-mouse on
  set-option -g mouse-resize-pane on
  set-option -g mouse-select-pane on
  set-option -g mouse-select-window on


Learned Tmux a few weeks ago and use it every day now. You can enable Mouse Mode, on Macs you can install extra Tmux features, and iTerm2 has mouse mode built in.


If you really want this, you should use a tiling window manager and use "focus follows cursor" or "focus on click".


Why it's 2.0? I don't see any really significant changes, or maybe I missed smth.


tmux is an OpenBSD-influenced project. Those projects' version numbers often progress from N.9 to N+1.0 without having any special significance.


Maybe because Tmux 2.0 has some breaking changes??


They broke features between releases before without increasing the major version number.

While trying to use the same .tmux.conf over multiple versions of tmux 1.x, I often had to adapt the config file to settings being renamed or just going away without a deprecation warning beforehand.


like what?


  Incompatible Changes
  ====================

  * The choose-list command has been removed.
  * 'terminal-overrides' is now a server option, not a session option.
  * 'message-limit' is now a server option, not a session option.
  * 'monitor-content' option has been removed.
  * 'pane_start_path' option has been removed.
  * The "info" mechanism which used to (for some commands) provide feedback
    has been removed, and like other commands, they now produce nothing on
    success.


Still no true color support :-(


It looks like the true color ticket on tmux was closed out: http://sourceforge.net/p/tmux/tickets/140/

I was applying this patch to 1.9 on my machine and it worked well: https://gist.github.com/JohnMorales/0579990993f6dec19e83

Haven't had a chance to see if the same diff can be applied to 2.0 yet.


I tried the same patch on 1.9a but couldn't get it to work (tmux built fine but no dice with 24 bit colours). Very curious to hear if it works with 2.0.


a couple of people have asked me about how true colour should look but none have sent code so far, it's not a very interesting feature to me so it'll need someone who cares about it to do it


The release notes don't say:

Is this a session-breaking update?

I'd hate to run the update only to have it kill my current TMUX session.

Devs - if you're reading this: PLEASE indicate if I could update without restarting the session.


Does not appear to be a session-breaking update. I just updated with no ill effects.


Actually, I already provide this in the release notes. A PROTOCOL_VERSION bump means restarting tmux. We didn't do this between 1.9a -> 2.0, hence why it wasn't mentioned. Look at the release notes for 1.9, you'll see it was mentioned there. Simples.


have you tried something like tmuxinator so create/restore sessions?


May I suggest a more lightweight alternative for Tmux/Screen/DVTM sessions - http://zserge.com/blog/mucks2.html ?


This is great news! But I've started to use Tmux less after being REALLY into it. I've slowly replaced it with a tiling window manager because I've noticed my ncurses and curses programs don't draw right in Tmux. I've found a couple work arounds, like using the TERM env var, but it doesn't work for everything.

I'm wondering how others have solved this problem, if they have at all.


I run into the opposite. St doesn't play well with n/curses in my experience (mostly corrupt characters on display), and the easiest solution I've seen is to run these programs in a Tmux session. I use Tmux all the time anyway, so this doesn't add any extra overhead for me (mental or system).


I wish it was possible to have screen-like bindings that don't require explicitly defining them all so that you don't have to unpress Ctrl each time. In screen you can press C-a c quickly but for that to work in tmux you have to add this:

bind-key C-c new-window


Is line 2 what you are looking for? https://github.com/kusold/dotfiles/blob/master/tmux.conf#L2

I just tried it out, and `C-a c` created a new windows for me.


Tried that before and with 2.0 but it doesn't work. You still have to release both 'Ctrl' and 'a' before pressing 'c'. In screen you don't have to and chaining works comfortably.


> In screen you can press C-a c quickly

Screen just binds C-a c and C-a C-c to the same command, for some values of c.


Holy moley, I knew there were 24 function keys at one point, but 63? That's crazy! I love learning little things like that.

I'm definitely glad modifier+key shortcuts are so common. I like it when shortcuts can be somewhat mnemonic (and I love vim).


I don't see anything about it, so I'm assuming there's still no support for "true" (24 bit) colour? Would really love if they added that, since Neovim now supports it.


Does anyone have Tmux 2.0 working alongside Tmuxinator? I know the project only claims support for 1.8, but I've been using it alongside 1.9 (mostly without issue) for many months.


This is still failing:

   bind-key -t vi-copy Y copy-end-of-line \; run-shell "reattach-to-user-namespace -l zsh -c 'tmux save-buffer - | pbcopy'"


I'm excited by the improvements in the pane navigation. I'd have to try it out to get the feel of it but looks like an improvement.


I really want tmux or screen to just scroll when I mouse wheel up or press the up arrow on the selected window.

I don't like having togo into copy mode.


What's wrong with `setw -g mode-mouse on`? Or I simply didn't understand the point.


This new release breaks emacs' cursor with iTerm2 :(. Works fine with tmux + Terminal or iTerm2 without tmux though.


>CHANGES FROM 1.9a to 2.0 6 March 2015

I think they meant 6 May 2015?


Anyone else slightly disappointed that connecting to a tmux session with mosh breaks mouse-mode? That fixed, plus session restore, would be the dream.


i suspect you need to talk to the mosh guys for this


True enough. The session restore still stands. I know tmuxinator exists, but as a personal preference I'd prefer it in-built/native. Also to save state, which I'd expect is asking too much.


what do you mean session restore? we could restore the basic layout of sessions, windows, panes but we couldn't restore what was run in them (and it would be dangerous to try)


brew install tmux

to install on osx. If you already had tmux

brew unlink tmux; brew install tmux


Yes, without unlinking, some people are probably going to experience this effect:

>brew install tmux

Warning: tmux-1.9a already installed

Then again:

>brew unlink tmux

Unlinking /usr/local/Cellar/tmux/1.9a... 4 symlinks removed

>brew install tmux

Warning: tmux-1.9a already installed, it's just not linked


I'm looking forward to the combination of Tmux and Neovim. Both (will) support detached/shared sessions, both are scriptable/configurable, both can be driven by a remote process. I believe with Tmux and Neovim you could put together anything from a simple test/editing environment to a full-blown IDE.


Unfortunately, Tmux still doesn't support true-color, which nvim added recently. I was hoping for it in the 2.0 release.


Well, no need to really look forward... You already have every one of those capabilities with Emacs.

>you could put together anything from a simple test/editing environment to a full-blown IDE.

People already do this with Emacs.


You're not doing a good sell for Emacs. People choose vi because of modal editing, not because they are ignorant of the Emacs feature set. You should at least say, "If you like vim for its modal editing features, but would also like support for session detachment along with a host of other stuff, you might find Spacemacs, or emacs with evil mode setup, a good alternative. There's a little bit of a learning curve, but it may be less than you think depending on how customized your vim setup is."

As someone who switched a few weeks ago, I would find that a much more intriguing breadcrumb trail.


> People choose vi because of modal editing, not because they are ignorant of the Emacs feature set.

Exactly this. I had used Emacs for many, many years and finally decided to give Vim a go... and never looked back. Emacs is very powerful, and while the Elisp infrastructure has distinct advantages over Vimscript, the compositional richness of Vim's editing model is amazing. I don't have to drop to scripting because Vim gives me the power I need more quickly and easily.


So, that said, have you tried out spacemacs? It's really, really good. It's not a zero cost switch, but I really think it makes the good things about vim work in emacs.


Curious that you chose to switch editor outright rather than just install some more modal package, after all those years. I chouse the former as the path of least resistance.


That choice was actually motivated for other reasons rather than just the modal workflow. The biggest of which was that (at the time) I found I had to really struggle to get Emacs and its ecosystem to play nicely with a highly project-centric workflow. I had used old vi regularly starting decades ago, and thus had basic usage burned in. E.g. I never understood these seemingly lame "minimal system editors" that some distros use vs. the old sysadmin standard of a minimal vi implementation (vs. full vim, emacs, etc.)

But it was becoming clear that something else was going on with modern vim, so after testing the waters a bit for my needs, I decided to go all-in as much as an ecosystem research project as anything else.


Last time I tried ansi-term and friends (not that long ago), it was very slow and struggled rendering my fairly vanilla (by some people's standards) shell prompt. Neovim's terminal emulation, by contrast, is a very great deal faster and can run Neovim inside itself with no discernible issues.


That's not actually a feature that was listed (because it's a pretty useless feature - I don't know anyone who actually uses ansi-term rather than screen/tmux, M-x shell or M-x eshell, and likewise it's not going to be useful for neovim to embed a terminal, the useful part is integration.)


Emacs is great and I know lots of people who love evil mode. I prefer vim because it comes pre-installed - good for ops. Many of my tools have embedded Lua, so it's great that I can exercise my Lua skills with Neovim. None of my other tools embeds elisp, so for me, elisp is a dead-end.


Neovim won't be preinstalled for a long time. Possibly it never will be. Also, writing Elisp is not far from writing Guile Scheme, and there are many tools that embed Guile.


True that Neovim won't be preinstalled, but for ops all I need is basic editing and the ability to leverage my vim muscle-memory.


But you can already script vim...


Only with blocking operations, though.


Yeah but - I like Neovim's msgpack-api, and the built-in terminal emulation. On the Neovim roadmap: attach/detach from a background session, multiple screens with different sizes.




Applications are open for YC Summer 2018

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: