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

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.

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.

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.

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.

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.

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.

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.

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 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.

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

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

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.

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

This is exactly why I use adblock.

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.

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.

or http://scribblestrum.livejournal.com/88086.html for those without a New Yorker sub.

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"

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.

...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.

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

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

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.

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.

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

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

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)

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?).

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.

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 :)

In iTerm, this would be a start command of:

    login -fp YOUR_USERNAME /Path/To/local/bin/mux --prompt

    mux <session_name>

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

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

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 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.

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

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)

Liking the plugin you wrote!

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

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

<bind>z

So you can remove this line from your config:

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

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

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-s will suspend the terminal on some platforms. (Which can be resumed by C-q.)

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.

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.

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.

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

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

Anyone using that instead ?

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

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?

    tmux show-buffer | vipe | bash -
    tmux send-keys -t debugger run

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

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

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

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.

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.)

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.

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

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.

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.

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.

  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

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.

  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.

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.

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.

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

bind-key C-c new-window

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

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

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

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

I don't like having togo into copy mode.

I think they meant 6 May 2015?

to install on osx. If you already had tmux

brew unlink tmux; brew install tmux

>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

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

People already do this with Emacs.

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

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.

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.