Fun fact: The ssh-agent equivalent for Windows that ships with PuTTY (pageant) has a limited amount of memory reserved to store the actual keys (8kb) which causes it to stop responding when more than 25 keys or so are used. Because they have no GitHub, no easy way to collaborate on the source, and the developers don't reply emails, this has gone unfixed for years, and even though PuTTY is open source and you can fix it yourself and use your build (which we did), the worst is that we quickly found out that almost every independent tool on Windows that relays on SSH copy pasted the source of PuTTY almost verbatim, since we found this bug in many places afterwards, including closed source applications.
Bottom line, set your workflow on Linux or at least bash for Windows if you manage or plan to manage many machines.
I very rarely use Windows but one particular client has a VPN that only works in Windows so I recently switched from Kitty to Cygwin and am much happier.
Configured mintty with solarized colors, source code pro font and it's as good as it gets on Windows.
No Github, so what? If it was on Github but developers still unresponsive, what whould've changed? You'd still need to fork and/or publish your patch somewhere.
Coming from Linux/macOS, PuTTY was one of the things that always drove me bonkers. So much clicking to change settings. So many times I was uncertain about whether I'd edited or saved the right session.
I'm trying out Windows again, and the whole environment seems to have massively improved in the four years since I last played with it: after installing bash for windows and docker for windows and openssh through scoop, I can open a command line and use native ssh, or type "bash" and use the usual Linux version, or "docker run ..." and use whatever I'm used to there. Given all these great options, it's not clear to me why anyone would go back to a separate GUI tool?
> Given all these great options, it's not clear to me why anyone would go back to a separate GUI tool?
You're clearly a Linux person. Or at least a command line person. I am too. Quite a few programmers at my work have never used anything but Windows and barely touch any servers. So they don't really use the command line at all, ever.
They also insist on using graphical clients for Git. This is of course horribly inefficient and leads to plenty of problems (mostly due to their choice of the Eclipse Git Client, which seems to have a lot of bugs). But they think the command line is scary and too difficult to understand.
So, my point is, there are a lot of people who have used GUIs their entire life and are used to be able to figure things out by just staring at the GUI and spending 30 minutes aimlessly clicking about. Then when they use a CLI program they have no idea what to do, and get frustrated. Because they're not used to RTFM.
I use the command line for the majority of my day and I still use a Git GUI (Tower for Mac) because in one single window I have all my repositories traversable, I can instantly see what is changing, and get a diff of a file in one click without leaving the window.
For any commit/merge/push/pull standard maneuvers (probably 99.8%) I do, Tower is faster. Anything 'complicated' and I'm using git in the command line.
But I do agree about the Eclipse git client. It's the worst client I think I have ever seen. Every dev I know that relies on it regularly finds away to bork their local version or to screw up the central repository on a regular enough basis that it's not even a surprise anymore.
At work there are a few devs like that. I should specify that they are really good developers, and they are certainly able to work "the Linux way" if they have to, it's just that they are more comfortable using GUIs and "fat" IDEs rather than a CLI + a "lean" text editor.
Still, I am convinced that, for advanced users, CLI wins over GUI. Even outside of the sw dev world, I see many professionals (e.g. graphic designers) who, in order to increase productivity, learn so many keyboard shortcuts that they end up using their keyboard more than their mouse: in my mind, I see that as a "CLI-zation" of the GUI.
Another point is ease of sharing: with CLI-based work-flows, you can just write down everything in the company wiki, all is just text. The thought of having to take screenshots in order to describe a work-flow to a colleague (vs. just writing down commands) drives me mad.
I recommend GitHub Desktop to most of my coworkers that come to me with git problems. It's nice in that it also installs a command line version of git that I use with Powershell. In that sense it is useful because they can grow into power users should the need arise.
Ah ok, I'll let my Eclipse Git coworkers know about this. Shame there isn't a Linux version or I could give it a go myself to see how it compares. I assume it does branching well.
Look at the Session GUI. You can click on a list of saved sessions, but they won't show up in the input configs at the top till you press load, but if you doubleclick on them a new session is started.
> Look at the Session GUI. You can click on a list of saved sessions, but they won't show up in the input configs at the top till you press load, but if you doubleclick on them a new session is started.
Of all things, I don't think that is a bad design choice. I would get really annoyed if all the changes I've made in the different tabs were to disappear because I happened to click on one of the already existing sessions in the list. Perhaps because I'd want to update it.
We wanted to switch to Git from Mercurial because we wanted something like Gitlab. The only reason we didn't was that there wasn't any app for Git which was as user-friendly as TortoiseHg.
We considered switching to Git as well for a similar reason (GitLab). However we discovered Phabricator provides similar toolset at GitLab and also supports Mercurial. It's open source - you can run a local instance (no cost but also no support) or pay for them to host. They also recently started a free plan where they will host an instance with up to 5 users.
1. Check out Gogs (Github clone written in Go). Gitlab is quite heavy, we would've needed an extra machine to run it, so we tried Gogs and absolutely love it.
2. Using the command line is actually quite helpful the get in the "git mindset" (and workflow). Give it a try and you won't want to go back to gui tools.
3. Assuming you are on Windows, check out Github Desktop and Tower.
Which pales in comparison to the multi-platform goodness of TortoiseHg since it is an independent creation designed from the ground up for the distributed workflow rather than a reworked TortoiseSVN. I wish someone would do a Git conversion of THG.
I highly recommend you give SmartGit a try. The best way I can describe it is it feels like an IDE for Git/Mercurial. In a similar vein to TortoiseHG. Unfortunately, it's paid software, but one of the few pieces of paid software that I'll ever recommend.
Have they fixed their exrreme performance issues yet? For years the product was completely unusable because simple operations like marking a file would take 10secs while maxing out your CPU. Google for it and you will find many threads on their forum, all with various hacks and solutions that some times work and some times doesn't, the problems seem to be machine dependent so some people get the problems while others dont and they can easily ignore fixing the issues permanently. I haven't bothered to try any updates for the past year since I lost faith in them.
A shame, because otherwise the product looks good and has a good workflow.
>Quite a few programmers at my work have never used anything but Windows and barely touch any servers. So they don't really use the command line at all, ever.
>They also insist on using graphical clients for Git. This is of course horribly inefficient and leads to plenty of problems (mostly due to their choice of the Eclipse Git Client, which seems to have a lot of bugs). But they think the command line is scary and too difficult to understand.
I still find it hard to believe that there are people like this out there.
You're a programmer! You write in programming languages all day, but you think at a new language, a relatively simple one used by thousands of people who aren't professional programmers, will be hard to learn.
I guess Steve Yegge was right. Programmers really do hate learning new languages.
Those people are the majority (or at least a large plurality). Quit your job as a game dev/web dev at a large software vendor/startup and join the enterprise Java/.NET devs working on middleware and be amazed at how scared they are of anything outside of the IDE.
The thing is, I actually can't imagine what it's like to be those people. I mean, I'm trying, but I literally can't: I log into my computer every day over SSH, I write and use CLI tooling constantly. I'm an emacs user, and if your tooling doesn't have a CLI mode, I'm usually not interested.
I can't stand IDEs and frameworks because I hate having things done magically for me, partly because "magic" tends to break, and partly because I have a compulsive need to know how things work, if not deeply than at least superficially. I can't stand Java and languages like it because the absurd amount of boilerplate they generate seems to require such things, it's generally considered a fool's errand to write Java outside of an irritatingly complex IDE, and it seems to attract complex frameworks like a pile of crap attracts flies.
An IDE dependance (not preference, dependance: you're terrified of going outside of an IDE) doesn't just imply a distaste for CLIs, it often implies a desire to have things done for you, for "magic."
Do these sorts of people rewrite software, even if there's a convenient framework, just because? Do they think about cache misses (even if they don't do anything about them)? Do they learn new languages and concepts on a whim, because, "I thought it seemed cool?"
Thinking like these people doesn't just mean ignoring years of knowledge, but also actually pretending that a deeply ingrained part of who I am, something I though near intrinsic to programmers (because what other sort of person would do this sort of thing voluntarily?).
There are many people who are completely lost without an IDE, or even without their IDE. Some of them have no idea of what is going on underneath. It is not rare to read such people around here.
That's... terrifying. I mean, I am often in awe of my own staggering ignorance, but at least I'm doing something about it. I hazily know how CPUs work (more or less), I understand why cache misses matter (now: thanks HN). I understand the basics of Big O, what kinds of functions are computable, and why O(n^2) or O(n!) is really bad. I know some common algorithms for simple problems, and I know how to recognize the Travelling Salesman when I see it.
That's not all that I know, not by a long shot, but I know that what I know is a tiny drop in the ocean of what I don't.
It's just baffling that there are people out there, likely older than me, who aren't actively trying to learn more. I mean, if you don't like computing enough to be motivated to learn more about it, why are you in the industry?
It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything. You didn't have to read anything or search around in order to change all of those settings in the GUI.
If I were just transferring files or editing files remotely I would use WinSCP which has a much better interface than PuTTY. I can't stand browsing files through the commandline on any OS... It's so tedious.
Also, you can operate the entirety of Windows with just the keyboard. You don't even have to pick up the mouse at all. The Tab and Enter keys get you pretty far without even having to know anything special.
> It's never been clear to me why anyone would want to use a completely opaque and undiscoverable interface such as a commandline over a nice GUI for anything.
The command line gives you both a larger learning curve (base) and greater capabilities (peak). It's not possible to put all the options from the command line into a GUI, because piping allows you to stitch unrelated commands together to form, on the fly, entirely new "programs."
for f in *.gz; do gunzip < "${f}" | tr '(' '\n' | awk -F "'" '{print $2}' | grep -v -e '\.foo$' -e '\.bar$' > "out_${f}.txt"; echo "${f}"; done
The above command is pretty simple (and could possibly be improved, as many awk+grep combos can be), but I can't picture it in a GUI. Additionally, the above command will still work 10 years from now, whereas the GUI will have changed. So from that perspective, a CLI user who has already reached "base camp" will have a lower learning curve than a GUI user, who will continually have to re-learn new interfaces.
That sounds like a really complicated command, requiring countless amounts of keystrokes and indepth knowledge of the CLI (piping, etc) and the commands (tr, awk) involved.
Something that could easily be solved with a bit of copy-paste and regex usage in the right text IDE. I'd argue that you're comparing a seasoned professional at the CLI with an inexperienced IDE-user. It's always assumed that IDE and non-CLI users are basic and not at all adept at performing their tasks in efficient ways.
If you had to program by point-and-click, I think you'd find it very slow and cumbersome (in spite of valiant efforts to make this kind of thing work, like lighttable). Your immediate reaction in the face of a task to do something conceptually simple, but with an annoying number of little steps, is to reach for a programming language and build it in your IDE. It would be more convenient, really, if you had an IDE that was specifically designed to work with all the other applications on your system, rather than just with whatever language you're using and its libraries. And there is such a thing: the shell! With things like tab-completion, history, aliases, and man pages, the unix command line interface basically already is an IDE. While I don't yet have enough experience with it to say for sure, it seems like PowerShell is intended to be similar, even going so far as to have a literal IDE (PowerShell ISE).
There's a reason why IDEs always seem to have a built-in terminal, and why those which didn't at first seem to grow terminal-like capabilities, like VS Code's command palette.
For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful.
Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE.
Granted, GUIs can offer a lot of advantages - if I'm moving data between two different computers, I will almost definitely use WinSCP, unless it's someone I need to script, simply because the interface is clean, straightforward, and I've never yet had to worry about side effects. And obviously, I use a browser like Chrome and an email client like Gmail. But there are some things where the GUI just adds way too much complexity that I don't ever want to deal with.
>For me, at least, I feel much more in control of what's actually going on when I'm working on the command line; once you hit the GUI level, there's another layer of abstraction that you have to understand and deal with that in a lot of cases isn't very helpful.
>Case in point, right now I'm an undergrad TA'ing a C++ class. One thing that has been very useful when helping students out is compiling their code under Clang and GCC, which for me, is as simple as just changing `CXX` when I cmake their stuff. But hell if I have any idea how to change that easily in their IDE. It's also easier for me to redirect compiler output somewhere so I can look at it, and for maybe everything except step-by-step debugging, I have pretty much no need for the IDE.
Probably because the GUI tools you're using are CLI first, with GUI frontends being a second thought? On Visual Studio (which is GUI first), changing a compiler is as simple as going to project properties and clicking the toolchain dropdown menu.
Scriptability is just as important as discoverability. I don't feel like constantly clicking to accomplish the same task when I have a ton of scripts written down which accomplish a lot of repetitive tasks without clicking.
What about the first time you are using the program? You certainly do need to read all the menu options and search around until you find the correct settings to tweak.
No matter what interface you use there is always going to be an initial learning curve, some people prefer the CLI and others prefer the GUI, there's nothing wrong with that.
True, could not get used with putty myself also. But since I upgraded to Ubuntu I started using only PacManager as my primary ssh connection manager and never looked back
I used MobaXterm for the better part of a year on a paid license. It was a reasonably good terminal, though I absolutely HATE the way they included the kitchen sink and then some in their app. Most of it was just cruft and they also seem to have decided not to use some standard things in terms of the GUI itself... rather than using one of the usual GUI toolkits, they seem to use something that is either home-grown or something I don't commonly see: wasn't so good on my high dpi displays.
I no longer use Moba and have replaced it with a combination of conemu (https://conemu.github.io/) for the shell improvement side (the larger rationale for using MobaXTerm in my case... MS shell being less that good), Windows Subsystem for Linux (for the cygwin stuff in MobaXTerm, and I just use SSH from there) and PuTTY Pageant for windows SSH agent and Bitvise for easy tunnels (https://www.bitvise.com/ssh-client). That may seem like a lot, but each part gets used for its strengths and its all really, really simple (and not all used at once.)
Totally agree, I don't know why there's such a blind spot for MobaXTerm. You can run up multiple copies of the free version to get around most of the limitations (I even do that with my paid for edition because I get better session tab management) .
i'd not heard of it before; it does look like it has some very nice features. wonder why it didn't come up when i was searching for a windows sftp client recently.
Honestly, the #1 terminal program is SecureCRT and its worth paying for. The only reason: There are two great and efficient ways of managing logins and session information. I wish there way an open copy of SecureCRT but I've yet to find one and SCRT is cheap enough to where I just stick with it. Kitty is interesting but I wish session management was scrt style.
Try mRemoteNG. It's not quite SecureCRT, but I switched long ago and haven't regretted the move. It has a nice tabbed UI and supports many protocols (ssh, RDP, VNC, etc.). It has recently returned to active development.
Isn't `ssh` the best SSH client in the world, despite the KiTTY's claim? Not to mention, that I'd describe PuTTY/KiTTY more like 'only usable ssh client on windows platform' rather than what they're claiming on their website ;)
Maybe that was true 2 years ago. Now Microsoft is maintaining OpenSSH for powershell and there is Bash for Windows providing direct linux binary support.
IMO just abandon the crutch provided by PuTTY and use Cygwin + Console2/ConsoleZ/Conemu. You'll get the "official" SSH, with support for normal SSH keys, a rather complete and solid Unix tools setup plus a decent terminal wrapping the Windows console. You'll also be able to switch between Cygwin / cmd / Powershell with ease.
I've always had issues with these wrappers around Putty, in that they never seem to deal with focus correctly.
My biggest issue with KiTTY was that it saved the username for subsequent windows - which was really hard to deal with when i'd mistyped the name! Anybody know a keyboard shortcut to forget which user was entered?
TTYs are a kernel feature which aren't present at all in Windows. It's not clear how one could "port" them, short of writing a driver (which I'm not sure is even possible).
One of the most annoying things about PuTTY is that the black default background is too dark to see. For example, I always have to change it to light background because I can't see my VIM buffer very easily. It also handle the alt arrow keys.
The first line of the release notes is the following sentence: "This is a pre-release (non-production ready)".
Microsoft's implementation includes the full sshd. While I'm happy they're finally onboard with that (could have used it 10 years ago), that's overkill compared to PuTTY/KiTTY.
Yeah, there are a few things that annoy me about Putty but not enough to actually switch. Granted, Putty is pre-installed on every machine I touch that doesn't have ssh natively installed, but for the most part it just works. All the problems I have with it disappear as soon as I'm logged into a remote server.
Well, I would guess first and foremost: why change? People that already use putty probably have no desire to switch just to switch. If the alternative isn't SIGNIFICANTLY better, most people aren't going to switch just to switch.
Second: not everyone is on Windows 10 which is a requirement for the Linux subsystem.
I guess last but not least: in both cases they require installing software. Some corporate users have no control over their own laptops. Putty has a portable version that you don't have to install anything to use.
Bottom line, set your workflow on Linux or at least bash for Windows if you manage or plan to manage many machines.