8 ms·

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". https://gi

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". https://github.com/mobile-shell/mosh/issues/1115 https://github.com/mobile-shell/mosh/issues/1115

eyelidlessness 5y ago
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.
- slg 5y ago
  I don't know how anyone could have avoided being in some stage of burnout over the last, let's say, 17 months.
  - OtomotO 5y ago
    The last 18 months were the best of my life. Not looking forward to what the majority calls "normal"
    - eyelidlessness 5y ago
      I assume this means you’re working remote and it benefits you? If so, that’s awesome and it should be accommodated! 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!
  - eyelidlessness 5y ago
    I don’t disagree at all! But let’s just say I’m waiting out a severance contract before I talk in more specifics about mine because damn.
xyst 5y ago
why hasn't someone just forked it and make a "mosh-alt"? seems like the most logical step to me.
- foxpurple 5y ago
  Because 99% of open source software has about 1-3 real devs and after they give up there is no one who can be bothered to take over. Several older projects like X11 and CUPS have no real developers anymore.
  - shp0ngle 5y ago
    Yep. It's trivial to fork, not trivial to maintain. Especially when it's something where security is important - mosh will allow anyone to connect to the server directly if there is a bug there.
- shp0ngle 5y ago
  There is 600 forks on github.
  - ericpruitt 5y ago
    How many of these 600 forks have unique code i.e. aren't just snapshots of the canonical repository? A lot of people use the fork button as a way of bookmarking or mirroring in case the canonical repo disappears.
  - da39a3ee 5y ago
    That's because Github, in their early days, got very confused about what forking was and made banners saying "Fork me on Github" when what they actually meant to say was "Star me on Github".
devin 5y ago
i didn't know that, and that bums me out. is what's there good enough to not care that there aren't frequent updates?
- banana_giraffe 5y ago
  Certainly for me it's been good enough, I use it daily and haven't run into any issues. I know people mention there are issues with some Unicode characters. Somehow I've never hit those issues, so I'm happy.
  - shp0ngle 5y ago
    There are some issues with colors too
  - keithwinstein 5y ago
    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 the client AND server. (I think the model of "libc implements wcwidth" probably made more sense in the era before Unicode decided to start pumping out new releases every year with lots of new characters everybody wants to use. But we try to keep Mosh's own attack/implementation surface small.)
    - faho 5y ago
      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 change it!). So we've made something we call widecharwidth (https://github.com/ridiculousfish/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 https://github.com/mobile-shell/mosh/pull/1143
rattray 5y ago
Elsewhere on the thread people recommend et as an actively-developed alternative with scrolling support: https://eternalterminal.dev/ https://eternalterminal.dev/
keithwinstein 5y ago
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 that person is currently, I think, dealing with a bunch of stuff (look around the world the last year...). I'm not eager to step back in and bigfoot them -- especially when I'm no longer particularly familiar with the codebase (and recent commits) as I used to be. 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. :-)
- Hnrobert42 5y ago
  I don’t use mosh myself as I thought the project had been abandoned, but I know several folks that love it. Just want to thank you on their behalf. 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.
  - goodpoint 5y ago
    I would not call a working and usable piece of software "abandoned". We should call it "completed".
TechBro8615 5y ago
That’s too bad. As a digital nomad, I wish that they would do more unpaid work for me so that I could use their software to perform more efficiently at my six figure job while riding the train to my next Airbnb.
jwr 5y ago
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.
OtomotO 5y ago
Finally, software that is considered finished and no "featuritis" taking over. I love that! KISS all the way!
- stunpix 5y ago
  Personally, I believe a good software should end up not in "we stopped releasing as we feature complete" but "from now we do only maintenance releases as we are feature complete" because the rest of the world is still evolving: apps, environments, OSes, some bugs could be sleeping for decades waiting to be discovered, etc. It's unfortunately an endless process to adapt even a finished project to a rapidly evolving world.
blueflow 5y ago
IT is one of the few places in the industry where its seen as a problem or a fault if a project is finished and fulfills its purpose.
solidsnack9000 5y ago
There needs to be a trust with a deed indicating the beneficial purpose of Mosh. Then the devs would be in a trust management corporation and could get paid for managing the project in the interests of the computing public.

eyelidlessness 5y ago

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.

slg 5y ago
I don't know how anyone could have avoided being in some stage of burnout over the last, let's say, 17 months.
- OtomotO 5y ago
  The last 18 months were the best of my life. Not looking forward to what the majority calls "normal"
  - eyelidlessness 5y ago
    I assume this means you’re working remote and it benefits you? If so, that’s awesome and it should be accommodated! 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!
- eyelidlessness 5y ago
  I don’t disagree at all! But let’s just say I’m waiting out a severance contract before I talk in more specifics about mine because damn.

xyst 5y ago

why hasn't someone just forked it and make a "mosh-alt"? seems like the most logical step to me.

foxpurple 5y ago
Because 99% of open source software has about 1-3 real devs and after they give up there is no one who can be bothered to take over. Several older projects like X11 and CUPS have no real developers anymore.
- shp0ngle 5y ago
  Yep. It's trivial to fork, not trivial to maintain. Especially when it's something where security is important - mosh will allow anyone to connect to the server directly if there is a bug there.
shp0ngle 5y ago
There is 600 forks on github.
- ericpruitt 5y ago
  How many of these 600 forks have unique code i.e. aren't just snapshots of the canonical repository? A lot of people use the fork button as a way of bookmarking or mirroring in case the canonical repo disappears.
- da39a3ee 5y ago
  That's because Github, in their early days, got very confused about what forking was and made banners saying "Fork me on Github" when what they actually meant to say was "Star me on Github".

devin 5y ago

i didn't know that, and that bums me out. is what's there good enough to not care that there aren't frequent updates?

banana_giraffe 5y ago
Certainly for me it's been good enough, I use it daily and haven't run into any issues. I know people mention there are issues with some Unicode characters. Somehow I've never hit those issues, so I'm happy.
- shp0ngle 5y ago
  There are some issues with colors too
- keithwinstein 5y ago
  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 the client AND server. (I think the model of "libc implements wcwidth" probably made more sense in the era before Unicode decided to start pumping out new releases every year with lots of new characters everybody wants to use. But we try to keep Mosh's own attack/implementation surface small.)
  - faho 5y ago
    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 change it!). So we've made something we call widecharwidth (https://github.com/ridiculousfish/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 https://github.com/mobile-shell/mosh/pull/1143

rattray 5y ago

Elsewhere on the thread people recommend et as an actively-developed alternative with scrolling support: https://eternalterminal.dev/ https://eternalterminal.dev/

keithwinstein 5y ago

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 that person is currently, I think, dealing with a bunch of stuff (look around the world the last year...). I'm not eager to step back in and bigfoot them -- especially when I'm no longer particularly familiar with the codebase (and recent commits) as I used to be. 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. :-)

Hnrobert42 5y ago
I don’t use mosh myself as I thought the project had been abandoned, but I know several folks that love it. Just want to thank you on their behalf. 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.
- goodpoint 5y ago
  I would not call a working and usable piece of software "abandoned". We should call it "completed".

TechBro8615 5y ago

That’s too bad. As a digital nomad, I wish that they would do more unpaid work for me so that I could use their software to perform more efficiently at my six figure job while riding the train to my next Airbnb.

jwr 5y ago

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.

OtomotO 5y ago

Finally, software that is considered finished and no "featuritis" taking over. I love that! KISS all the way!

stunpix 5y ago
Personally, I believe a good software should end up not in "we stopped releasing as we feature complete" but "from now we do only maintenance releases as we are feature complete" because the rest of the world is still evolving: apps, environments, OSes, some bugs could be sleeping for decades waiting to be discovered, etc. It's unfortunately an endless process to adapt even a finished project to a rapidly evolving world.

blueflow 5y ago

IT is one of the few places in the industry where its seen as a problem or a fault if a project is finished and fulfills its purpose.

solidsnack9000 5y ago

There needs to be a trust with a deed indicating the beneficial purpose of Mosh. Then the devs would be in a trust management corporation and could get paid for managing the project in the interests of the computing public.