7 ms·

Warp engineer here. FWIW, the Warp terminal will be free for individuals. We would never charge for anything a terminal currently does. So no paywalls around S

Warp engineer here. FWIW, the Warp terminal will be free for individuals. We would never charge for anything a terminal currently does. So no paywalls around SSH or anything like that. The types of features we could eventually charge for are team features. Our bet is that the moat is going to be the team features, like: - Sharing hard-to-remember workflows - Wikis and READMEs that run directly in the terminal - Session sharing for joint debugging Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context.

ThemalSpan 4y ago
What would be the advantage over version controlled shell scripts?
- steveklabnik 4y ago
  (Not affiliated with Warp but care about this particular thing) Shell scripts implies, well, a particular shell. If everyone is on similar OSes, maybe that works for you, but as a Windows user, "pile of bash scripts" might as well be "doesn't work for you." I use a terminal for my daily work, but don't have bash installed on my machine. That said, I haven't tried Warp yet specifically because it's Mac-only right now. Even within that context, Warp integrates with Bash, Zsh, or Fish, which do have their own extensions to POSIX shell, but at least you can rely on Bash being installed.
  - andrewzah 4y ago
    That would also now force everyone to use this proprietary product instead of whatever they're familiar with. For mac <-> linux, posix-compliant scripts mostly work in my experience but you have to account for different versions of gnu utils. For linux <-> windows, if it's small you could just write a powershell script, or use something like python on both, no? I fail to see how these features are nice enough to force people to use a proprietary terminal that, for now, is compatible with existing bash/zsh shells.
    - steveklabnik 4y ago
      Yes, that is true, but it does seem like that's what their strategy is. If you're using these collaboration tools at your job, you'd have to be using the product already. So that's less of a problem than it would be for say, scripts included with some sort of open source project. My point is mostly that shell isn't cross-platform, and this is one way you could address that. But it's not a generalized solution, absolutely. (and yeah, something like Python is better than trying to keep multiple of the same scripts in different languages, for sure. You can do it if you wanted though, if they're small and you're willing to commit to it, I'm not sure I've ever seen it really pulled off.)
      - iskamag 4y ago
        >shell isn't cross-platform basically every operating system has a posix shell by default except windows, but it has been ported there multiple times, samba existed for decades and WSL is on the rise. It may sound a little more irritating but they deserve it for still running windows :p /hj (besides you can just host an ssh server)
        steveklabnik 4y ago
        I mean, I could also tell you "Just download and run PowerShell, it's ported to Linux", but you also know that would make you feel like a second-class citizen, because you know it's not something as good as something that actually works on your platform in a real sense.
  - colonwqbang 4y ago
    Why would it be easier to port Warp to a new system compared to Bash, Python, Perl, etc.? These tools are widely used to automate workflows and are already ported to any system you would probably care to develop on.
    - steveklabnik 4y ago
      You aren't the one porting Warp, but you are the one porting the shell script.
      - colonwqbang 4y ago
        So programs/workflows written in Warp will be portable without much effort, in some way that an equivalent shell or python script isn't? Why do you think that?
        zekrioca 4y ago
        Thats a good question. In the end Warp programs/scripts will be written in just yet another interpreted language.
        steveklabnik 4y ago
        It seems like you’re grouping a bunch of things together and saying I have opinions about them that I don’t. Let’s break them out: workflows I would assume to be portable, yes. It is an assumption. I generally expect program configuration to be mostly cross platform by default. I’m not sure what a program written for a particular terminal would be, so I’m not sure if I’d assume portability or not. Shells are not ubiquitous, even if they are available across platforms technically. Python is truly cross platform and largely ubiquitous.
        colonwqbang 4y ago
        Ok, maybe I misunderstand what a "workflow" is. Since we are talking about replacing shell scripts with "workflows", I assumed that they are a kind of programming facility of about similar power as shell scripts. But that may be incorrect. > You aren't the one porting Warp, but you are the one porting the shell script. It sounds like your are saying somthing like "Warp scripts/workflows require almost no effort to port, compared to the shell scripts they replace". I was interested to learn how this can be the case. Perhaps my interpretation was wrong.
  - Fnoord 4y ago
    Nix(OS) already solves this problem.
    - steveklabnik 4y ago
      I cannot use Nix on my platform, and I’m not changing OSes.
      - Fnoord 4y ago
        Which platform do you use?
- alokedesai 4y ago
  That's a great question! Version controlled shell scripts are very useful (and in fact workflows in Warp can also be version controlled) but they still have a few problems: 1) Documentation--when a repo has a lot of shell scripts, it can be very difficult to know which command to run in certain situations. Even if each shell script has documentation, there's no way to find that documentation natively from the terminal itself. 2) Searching--you can only execute commands from the terminal based on the shell script name but there's no easy way to search for a script based on _what_ it does or any other metadata.
jbverschoor 4y ago
> - Sharing hard-to-remember workflows = Make better scripts and put in CI > - Wikis and READMEs that run directly in the terminal No thank you > - Session sharing for joint debugging = That's more for development.. not for shell access > Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context. I actually don't want them. I migrated from many apps that do too much to apps that do one thing really well.
wildmanx 4y ago
> The types of features we could eventually charge for are team features. You can probably maximize community acceptance if you provide clients that do not use these features as actual FOSS and only start incorporating closed-source pieces for those features. With things like client keys etc to restrict server access. A bit like the Chrome/Chromium thing was intended initially.
X-Istence 4y ago
> - Sharing hard-to-remember workflows Those get codified into ansible and deployed on CI/CD pipelines. This is an anti-feature. The day that someone suggests using a terminal to manage hard-to-remember workflows is the day I start a huge crusade to fix whatever process led to introducing yet another tool.
microflash 4y ago
> - Wikis and READMEs that run directly in the terminal Nushell can open READMEs natively and can admittedly work with Wikis through a plugin.

ThemalSpan 4y ago

What would be the advantage over version controlled shell scripts?

steveklabnik 4y ago
(Not affiliated with Warp but care about this particular thing) Shell scripts implies, well, a particular shell. If everyone is on similar OSes, maybe that works for you, but as a Windows user, "pile of bash scripts" might as well be "doesn't work for you." I use a terminal for my daily work, but don't have bash installed on my machine. That said, I haven't tried Warp yet specifically because it's Mac-only right now. Even within that context, Warp integrates with Bash, Zsh, or Fish, which do have their own extensions to POSIX shell, but at least you can rely on Bash being installed.
- andrewzah 4y ago
  That would also now force everyone to use this proprietary product instead of whatever they're familiar with. For mac <-> linux, posix-compliant scripts mostly work in my experience but you have to account for different versions of gnu utils. For linux <-> windows, if it's small you could just write a powershell script, or use something like python on both, no? I fail to see how these features are nice enough to force people to use a proprietary terminal that, for now, is compatible with existing bash/zsh shells.
  - steveklabnik 4y ago
    Yes, that is true, but it does seem like that's what their strategy is. If you're using these collaboration tools at your job, you'd have to be using the product already. So that's less of a problem than it would be for say, scripts included with some sort of open source project. My point is mostly that shell isn't cross-platform, and this is one way you could address that. But it's not a generalized solution, absolutely. (and yeah, something like Python is better than trying to keep multiple of the same scripts in different languages, for sure. You can do it if you wanted though, if they're small and you're willing to commit to it, I'm not sure I've ever seen it really pulled off.)
    - iskamag 4y ago
      >shell isn't cross-platform basically every operating system has a posix shell by default except windows, but it has been ported there multiple times, samba existed for decades and WSL is on the rise. It may sound a little more irritating but they deserve it for still running windows :p /hj (besides you can just host an ssh server)
      - steveklabnik 4y ago
        I mean, I could also tell you "Just download and run PowerShell, it's ported to Linux", but you also know that would make you feel like a second-class citizen, because you know it's not something as good as something that actually works on your platform in a real sense.
- colonwqbang 4y ago
  Why would it be easier to port Warp to a new system compared to Bash, Python, Perl, etc.? These tools are widely used to automate workflows and are already ported to any system you would probably care to develop on.
  - steveklabnik 4y ago
    You aren't the one porting Warp, but you are the one porting the shell script.
    - colonwqbang 4y ago
      So programs/workflows written in Warp will be portable without much effort, in some way that an equivalent shell or python script isn't? Why do you think that?
      - zekrioca 4y ago
        Thats a good question. In the end Warp programs/scripts will be written in just yet another interpreted language.
      - steveklabnik 4y ago
        It seems like you’re grouping a bunch of things together and saying I have opinions about them that I don’t. Let’s break them out: workflows I would assume to be portable, yes. It is an assumption. I generally expect program configuration to be mostly cross platform by default. I’m not sure what a program written for a particular terminal would be, so I’m not sure if I’d assume portability or not. Shells are not ubiquitous, even if they are available across platforms technically. Python is truly cross platform and largely ubiquitous.
        colonwqbang 4y ago
        Ok, maybe I misunderstand what a "workflow" is. Since we are talking about replacing shell scripts with "workflows", I assumed that they are a kind of programming facility of about similar power as shell scripts. But that may be incorrect. > You aren't the one porting Warp, but you are the one porting the shell script. It sounds like your are saying somthing like "Warp scripts/workflows require almost no effort to port, compared to the shell scripts they replace". I was interested to learn how this can be the case. Perhaps my interpretation was wrong.
- Fnoord 4y ago
  Nix(OS) already solves this problem.
  - steveklabnik 4y ago
    I cannot use Nix on my platform, and I’m not changing OSes.
    - Fnoord 4y ago
      Which platform do you use?
alokedesai 4y ago
That's a great question! Version controlled shell scripts are very useful (and in fact workflows in Warp can also be version controlled) but they still have a few problems: 1) Documentation--when a repo has a lot of shell scripts, it can be very difficult to know which command to run in certain situations. Even if each shell script has documentation, there's no way to find that documentation natively from the terminal itself. 2) Searching--you can only execute commands from the terminal based on the shell script name but there's no easy way to search for a script based on _what_ it does or any other metadata.

jbverschoor 4y ago

> - Sharing hard-to-remember workflows = Make better scripts and put in CI > - Wikis and READMEs that run directly in the terminal No thank you > - Session sharing for joint debugging = That's more for development.. not for shell access > Our bet is their companies are willing to pay for these. BTW, even these team features will likely be free up to some level of usage and only charged in a company context. I actually don't want them. I migrated from many apps that do too much to apps that do one thing really well.

wildmanx 4y ago

> The types of features we could eventually charge for are team features. You can probably maximize community acceptance if you provide clients that do not use these features as actual FOSS and only start incorporating closed-source pieces for those features. With things like client keys etc to restrict server access. A bit like the Chrome/Chromium thing was intended initially.

X-Istence 4y ago

> - Sharing hard-to-remember workflows Those get codified into ansible and deployed on CI/CD pipelines. This is an anti-feature. The day that someone suggests using a terminal to manage hard-to-remember workflows is the day I start a huge crusade to fix whatever process led to introducing yet another tool.

microflash 4y ago

> - Wikis and READMEs that run directly in the terminal Nushell can open READMEs natively and can admittedly work with Wikis through a plugin.