Note that Mosh has not had release for 4 years, even when pull requests are accepted on github, and the team lead says "we are too busy/burned out".
Mosh works as advertised and has never had a security hole -- we're pretty proud of that! We'll probably cut a release at some point to add those features (24-bit colors, the MacOS clock workaround) but I'm not feeling like it's urgent enough to upset what I had hoped was a transition plan.
It would feel arrogant to compare Mosh to TeX, but it doesn't seem that crazy to imagine that some software might reach a point where it has accomplished 95% of its goals, and the benefit from adding further features has to be weighed against the risk of introducing a security hole or other regression through further churn. If the TCP specification, or OpenSSH, or TeX, or GNU bash had canonical GitHub repositories, they would probably be full of a bunch of user support issues and inactive PRs too. :-)
Sorry if I mis-represented something.
I do wonder whether new releases are required to benefit from fixes and performance enhancements in libraries. Or is everything dynamically linked?
Hiding behind "well we don't want to compromise the core software" after stringing other contributors along for years doesn't pass the sniff test.
Also, I appreciate knowing you all are watching PRs and bug reports even if you don’t see the need to take action. Makes me feel the project is just dormant and not abandoned. If you care about continued use and adoption, you might consider posting an update to the website similar to this post you made here. If you aren’t worried about adoption, then no problem and thanks again for your effort.
We should call it "completed".
The ones where half of my keyboard shortcuts were acting funny (something like https://github.com/mobile-shell/mosh/issues/1147), or garbage left from some other screens/commands (https://github.com/mobile-shell/mosh/issues/1079).
Midnight Commander is also being drawn in a jumpy way.
Note that I'm not speaking about new emojis or some novel Unicode stuff, it's the same basic multilingual plane and line drawing characters we've had for decades now.
Paintings, books, movies... are finished with the bugs in.
Vulnerabilities need rapid fixes.
Every other bugfix requires additional effort and comes with the risk of introducing vulnerabilities or other bugs.
At some point 99.9% of the users are happy and the benefit of fixing another bug becomes marginal.
With all due respect, you pride on this matter should be no bigger than your userbase is.
A lot of Unix tools are like that. They do what they were written to do and that's the scope they're sticking with. It's fine if, maybe once in five or ten years, some support is added for a thing that grew outside the tool itself, such as interfacing a new system component. This conservative development might be a trait of the less-flashy command-line world.
In contrast, the desktop is full of programs that were in that good phase once but then development continued further, adding satellite features that just make the program worse until it's unusable even for the original purpose. Why not write another program to do the new things then, instead of packing everything into a single package? I don't know.
I like the philosophy here, if the software is “done” and there is no immediate need for security fixes, don’t touch it.
Maybe issue a point release where the only change is updating the documentation (man page, output of --version, ...) to state that it is 2021 and you are still here, stable, free of security issues, but not adding/updating features ATM. Then the project doesn't look dead (which can be a security concern) when it is in fact just quietly carrying on with achieving its goals without the need for changes.
The difference that I think makes this comparison invalid is that Mosh is a communication tool, whereas Tex is running locally on files. We (as a community) have learned that any software with a networked attack surface slowly gets less secure over time - you (almost always) need to provide ongoing security fixes to maintain the desired level of security.
To be clear - I'm not saying you're wrong. I'm an intermittent user of Mosh and I can believe that no holes have been found that need patching (and that the team would in short order if necessary). It is, however, a signal that users of software look for. I like the idea in a sibling comment of the "documentation" commit just saying "we're still here" to reassure people.
I think a lot of users look at the release history and cadence as a sort of heartbeat; in order to tell if a project is still being maintained. That can be a problem when a program reaches a mature state.
I can appreciate that, but what do you say to e.g. the contributor that added true color support nearly 4 years ago?
cgull also hasn't authored or committed anything in mosh in more than two years, so his inactivity predates the pandemic by quite a bit.
Everyone loves your software, and that's the reason they want to see another release with the many improvements already in git, most for multiple years. I really don't think you're going to step on any toes by making a new release.
Pretty please?
1) Has there ever been a full security audit?
2) if not and I run it inside a VPN (wireguard) doesn't that remove most of the benefits?
I've held off finishing and releasing half a dozen projects over the last year because while I think they'd be useful I know I don't have bandwidth to support them.
Not looking forward to what the majority calls "normal"
Edit: I take that (assume) back and wonder if there’s other social benefits you’ve gotten from isolating regardless of work conditions. I also support that if so!
KISS all the way!
I know people mention there are issues with some Unicode characters. Somehow I've never hit those issues, so I'm happy.
Specifically in the case of connecting to a server that typically has an old libc with old unicode information, from a desktop that has a much newer system, or in case of ambiguous characters, where libc will just give you one width that might not match what the terminal actually renders (and they frequently have configuration options to change it!).
So we've made something we call widecharwidth (https://github.com/ridiculousfish/widecharwidth), which is a python script that parses the unicode datafiles (UnicodeData.txt, emoji-data.txt and friends) and generates a header you can #include.
And someone's opened a PR to mosh to integrate it: https://github.com/mobile-shell/mosh/pull/1143
I think if we give up on libc, my "perfect" solution would probably be something like: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width (probably we can do this in some smart way) (b) client somehow communicates this info to the server at runtime, over the protocol.
But that's a lot of protocol work and kind of annoying. The good-enough solution might be: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width, or perhaps user just runs your script on the Unicode tables (+ user-supplied info about how their terminal handles ambiguous-width East Asian characters) (b) user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir.
I think the current maintainership has their own idea of what they want to do that's not quite this either.
Just to be clear: It's not my PR. The person who made that must've just seen widecharwidth and thought it was a potential solution.
>do we then have to push a new Mosh release every time there's a Unicode update?
In theory, yes. In practice the new codepoints take long enough to be available anywhere and there are few enough of them that being a bit out of date isn't a problem.
(case in point widecharwidth is still on Unicode 12 apparently - I should update that)
>user runs a script that prints every single Unicode character in their local terminal and learns its width
And they would have to re-run that regularly, whenever the terminal updates or they switch.
>user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir.
And they would have to do all that setup.
That's a lot of annoyance to put on your users when you can solve 99% of the problem by just incorporating a semi-up-to-date width table yourself.
The perfect is very much the enemy of the good here.
Funny that the volunteer open source maintainer is held to a higher standard than the trillion dollar company :-)
Something seems backwards about that…