4 ms·

Idk I wouldn’t mind one or two of these as loading screens or something.

by distortionfield 2y ago

JTyQZSnP3cQGa8B 2y ago
As a developer-only tool, I’m sure most of my coworkers would love the attention to details.
- PartiallyTyped 2y ago
  I actually love it.
- throwanem 2y ago
  As a product engineer, I'd love the attention to detail much more when placed toward changes that improve my ability to sustain velocity, than when toward changes that actively cut against that.
radlad 2y ago
What CLI tools have a slow enough boot to require a loading screen? I'm sure there are some but... The only one that comes to mine for me is FileBot[0] - and if the loading screen made it take ANY additional time, I'd be annoyed. [0] https://www.filebot.net/ https://www.filebot.net/
- distortionfield 2y ago
  Deployment scripts are what come to mind for me. I wouldn’t mind a cool loading screen that highlighted problem nodes in the burning font or something when I deploy to dev / test / hell, maybe even prod.
- hnlmorg 2y ago
  Anything that downloads from somewhere, eg rsync, wget, package managers, etc. Anything that compresses or decompresses archives, like gzip/gunzip, tar, etc. Anything that performs longer running recursive disk activities, like du, find, etc I’m sure there are plenty more scenarios I haven’t thought of. Though to be clear, I definitely don’t want to see this as a default enabled option in any of these.
  - jmbwell 2y ago
    If things are working well, they are automated and I rarely see the real time output. If I’m looking at real time output, it’s because I’m doing something manually because something isn’t working the way it’s supposed to, and I’m in no mood for anything that doesn’t help me understand and address the issue. This work is impressive. I love it. For some reason I really like “printer.” I’d be all about it for games or toys. But too many tools for real work try to do cute Unicode things or fancy colors or animations. I don’t need it on anything I will ever have to develop or troubleshoot, personally. After the first lengthy wait for a broken container to come up, I’m well over the colorful attitude.
    - hnlmorg 2y ago
      I deliberately mentioned stuff that people are likely to manually run on local and healthy systems. But yeah, I agree with you that the novelty of this stuff wares off quickly. An example of this done well would be ‘pacman’ package manager where an Easter egg can be enabled to turn the progress bar into a little Pac-Man gobbling pills. It’s not there by default, but it can be enabled if you know how. Personally, I’m in the same camp as yourself where I’d prefer our tools didn’t have all this cutesy stuff. But people like us seem to be a dying breed.
- rafark 2y ago
  Not for booting but for processing (downloading files, processing a directory, waiting for an api, etc)
- lupusreal 2y ago
  It could be cool for GUI programs, when run from a terminal, to show a terminal loading screen parallel to the gui loading screen. Totally unnecessary, but cool.
traverseda 2y ago
No. I still sometimes need to use a TTY over MOSH over a satellite connection. No.
- adrianmonk 2y ago
  In the old days, some software would actually check the terminal's baud rate (which you can see with 'stty') and behave differently on slow links. For example, vi would restrict itself to fewer lines of the screen so that drawing a new page didn't take as long. Although I don't know if much software does it, that should still be possible to do it, so these animations could theoretically be auto-disabled on slow links. (And you could manually override the baud rate in your mosh terminal if necessary since it doesn't really have any other effect in a virtual terminal, not like when using an actual serial port, I mean.)
- solresol 2y ago
  It shouldn't matter, should it? Mosh keeps the state and only sends the differences. You would miss most of the animations, and there would be the overhead of sending the colouring escape codes (a few percent extra), but other than that, it wouldn't be any slower than an unanimated version that I can see.

Idk I wouldn’t mind one or two of these as loading screens or something.

JTyQZSnP3cQGa8B 2y ago

As a developer-only tool, I’m sure most of my coworkers would love the attention to details.

PartiallyTyped 2y ago
I actually love it.
throwanem 2y ago
As a product engineer, I'd love the attention to detail much more when placed toward changes that improve my ability to sustain velocity, than when toward changes that actively cut against that.

radlad 2y ago

What CLI tools have a slow enough boot to require a loading screen? I'm sure there are some but... The only one that comes to mine for me is FileBot[0] - and if the loading screen made it take ANY additional time, I'd be annoyed. [0] https://www.filebot.net/ https://www.filebot.net/

distortionfield 2y ago
Deployment scripts are what come to mind for me. I wouldn’t mind a cool loading screen that highlighted problem nodes in the burning font or something when I deploy to dev / test / hell, maybe even prod.
hnlmorg 2y ago
Anything that downloads from somewhere, eg rsync, wget, package managers, etc. Anything that compresses or decompresses archives, like gzip/gunzip, tar, etc. Anything that performs longer running recursive disk activities, like du, find, etc I’m sure there are plenty more scenarios I haven’t thought of. Though to be clear, I definitely don’t want to see this as a default enabled option in any of these.
- jmbwell 2y ago
  If things are working well, they are automated and I rarely see the real time output. If I’m looking at real time output, it’s because I’m doing something manually because something isn’t working the way it’s supposed to, and I’m in no mood for anything that doesn’t help me understand and address the issue. This work is impressive. I love it. For some reason I really like “printer.” I’d be all about it for games or toys. But too many tools for real work try to do cute Unicode things or fancy colors or animations. I don’t need it on anything I will ever have to develop or troubleshoot, personally. After the first lengthy wait for a broken container to come up, I’m well over the colorful attitude.
  - hnlmorg 2y ago
    I deliberately mentioned stuff that people are likely to manually run on local and healthy systems. But yeah, I agree with you that the novelty of this stuff wares off quickly. An example of this done well would be ‘pacman’ package manager where an Easter egg can be enabled to turn the progress bar into a little Pac-Man gobbling pills. It’s not there by default, but it can be enabled if you know how. Personally, I’m in the same camp as yourself where I’d prefer our tools didn’t have all this cutesy stuff. But people like us seem to be a dying breed.
rafark 2y ago
Not for booting but for processing (downloading files, processing a directory, waiting for an api, etc)
lupusreal 2y ago
It could be cool for GUI programs, when run from a terminal, to show a terminal loading screen parallel to the gui loading screen. Totally unnecessary, but cool.

traverseda 2y ago

No. I still sometimes need to use a TTY over MOSH over a satellite connection. No.

adrianmonk 2y ago
In the old days, some software would actually check the terminal's baud rate (which you can see with 'stty') and behave differently on slow links. For example, vi would restrict itself to fewer lines of the screen so that drawing a new page didn't take as long. Although I don't know if much software does it, that should still be possible to do it, so these animations could theoretically be auto-disabled on slow links. (And you could manually override the baud rate in your mosh terminal if necessary since it doesn't really have any other effect in a virtual terminal, not like when using an actual serial port, I mean.)
solresol 2y ago
It shouldn't matter, should it? Mosh keeps the state and only sends the differences. You would miss most of the animations, and there would be the overhead of sending the colouring escape codes (a few percent extra), but other than that, it wouldn't be any slower than an unanimated version that I can see.