Test
Mosh: The Mobile Shell
71–80 of 158 posts
Re: Mosh: The Mobile Shell
#72Adding port forwarding to Mosh has a $600 bounty -- highest OSS bounty I've ever seen https://www.bountysource.com/issues/4471419-ssh-port-forward... https://github.com/mobile-shell/mosh/issues/337
On high bounties, Qubes OS has a $6500 bounty for GNOME support https://www.bountysource.com/issues/31778112-add-support-for...
Re: Mosh: The Mobile Shell
#73Earlier quoted context omitted.
As someone over a year into a burnout... good for them for guarding themselves from overextending. Maintaining a project is hard even if you have the whole of your energy and attention to devote. It's a lot harder when you're trying to power through. 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.
I don't know how anyone could have avoided being in some stage of burnout over the last, let's say, 17 months.
The last 18 months were the best of my life.
Not looking forward to what the majority calls "normal"
Re: Mosh: The Mobile Shell
#74Earlier quoted context omitted.
Unicode (really, knowing the width and printability of any given character) is mostly up to the C library on the client and server -- Mosh has historically stayed out of that. Unfortunately Apple is not always super-great about keeping their C library up to date with new Unicode releases, which leads to some frustration, and even on Linux it takes too long for a new Unicode release to percolate down to the libc on th…
With fish we've made the experience that relying on libc isn't good enough. 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 chan…
It's tempting, and thank you for the PR, but, do we then have to push a new Mosh release every time there's a Unicode update? And the users have to get this release installed on both the server and their client? It seems... like it fixes part of the problem, sure, by us taking on more of the load and locking us into an annual release cadence.
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.
Re: Mosh: The Mobile Shell
#75Note 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". https://github.com/mobile-shell/mosh/issues/1115
I think the truth is that we don't feel like we need a release. We've never had a security hole, our track record speaks for itself, and I wouldn't really want us to rush anything and blow that. There are some features that it would be really nice to have in a release (like 24-bit color support, and working around a recent MacOS clock bug), but I handed over the maintainership to somebody else about six years ago and…
A breath of fresh air!
Re: Mosh: The Mobile Shell
#76Mosh original author here -- fun to see us back here yet again. Happy to answer any questions.
I'm unable to use mosh after switching VPN clients, though ssh works. What should I discuss and/or request with the security+network folks?
Re: Mosh: The Mobile Shell
#77Note 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". https://github.com/mobile-shell/mosh/issues/1115
I think the truth is that we don't feel like we need a release. We've never had a security hole, our track record speaks for itself, and I wouldn't really want us to rush anything and blow that. There are some features that it would be really nice to have in a release (like 24-bit color support, and working around a recent MacOS clock bug), but I handed over the maintainership to somebody else about six years ago and…
Thank you for making a really nice thing and for keeping it that way.
Re: Mosh: The Mobile Shell
#78Earlier quoted context omitted.
With fish we've made the experience that relying on libc isn't good enough. 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 chan…
It's tempting, and thank you for the PR, but, do we then have to push a new Mosh release every time there's a Unicode update? And the users have to get this release installed on both the server and their client? It seems... like it fixes part of the problem, sure, by us taking on more of the load and locking us into an annual release cadence. I think if we give up on libc, my "perfect" solution would probably be some…
>thank you for the PR
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.
Re: Mosh: The Mobile Shell
#79Earlier quoted context omitted.
I think the truth is that we don't feel like we need a release. We've never had a security hole, our track record speaks for itself, and I wouldn't really want us to rush anything and blow that. There are some features that it would be really nice to have in a release (like 24-bit color support, and working around a recent MacOS clock bug), but I handed over the maintainership to somebody else about six years ago and…
Great response - not everything needs to be updated and upgraded every few days. Stability should be praised, not used as evidence of indolence.
I completely agree with the sentiment!
I do wonder whether new releases are required to benefit from fixes and performance enhancements in libraries. Or is everything dynamically linked?
Re: Mosh: The Mobile Shell
#80Note 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". https://github.com/mobile-shell/mosh/issues/1115
Mosh has been working great for me for the last two years or so, I don't feel the need for new features, so I don't see a problem there.