Live data from Hacker News

Show HN: Warp, a Rust-based terminal

warp.dev

671–680 of 757 posts

Re: Show HN: Warp, a Rust-based terminal

#671
post #20

Wanted to give it a shot but got disappointed when I launched it and the following happened: - 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 sen…

That’s concerning - I am also wondering if iTerm too sends this data…

Re: Show HN: Warp, a Rust-based terminal

#674

I see a lot of cool tech here all around. It's inspiring! Thanks! At https://github.com/warpdotdev/Warp How did you achieve to have the folders /keysets and /themes to be linked to the other git repos https://github.com/warpdotdev/keysets and https://github.com/warpdotdev/themes I wanted to do this for a long time but all tutorials pointed to all alternatives one more difficult than the other.

I think it's just a submodule

thanks! When I tried to look into it months ago I just got stuck in 2 hours reading of git submodule vs subtree and all the nuances. I like the way the submodule link is added by github. I'll just try that path and see how it goes, better than paralysis from analysis.

Re: Show HN: Warp, a Rust-based terminal

#675

Earlier quoted context omitted.

Shouldn't human interaction errors be left up to the user to report, as opposed to software sending sensitive information to a third-party?

In production, agreed. In beta, I’ll accept it. I feel that the term beta gets abused a lot, but in what I believe is it’s proper meaning, there are a lot of inherent factors both parties are agreeing to; increased risk of error and data loss, and debugging flags that generate more data for the singular purpose of improving the product. That’s exactly what should be in the privacy policy and explicitly stated upon in…

With you here on this. Telemetry is a really important concern and I get why people don't like it, but fundamentally the expectations on a beta product surely have to be different in that. The thing is still in development. T

Re: Show HN: Warp, a Rust-based terminal

#676
post #210

Earlier quoted context omitted.

I doubt their compelling features will be in OSS terminals any time soon. I’ve wanted a terminal that has a decent multi line editor for years , and there’s nothing out there.

This stuff has been in the major shells for years, through excellent editor integration. For emacs and vi it's pretty much free. If you want to integrate with a different editor, it's totally doable. 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.

Three words for 2 tests regarding these features:

1. discoverability

2. wide spread use.

Bash and zsh fail both tests.

Re: Show HN: Warp, a Rust-based terminal

#677
post #462

This is perhaps slightly orthogonal to the main discussion here on this thread, but I have a question for Zach (and the various engineers posting on this thread): Did you guys talk to real-world users while building this and before this launch? This whole blow-up re: your telemetry / open sourcey'ness seems like it could have been avoided. I'm curious if you actually floated these ideas with real world users and a) e…

Hey - in general, yes, we do talk to our Users on a regular about the product (in fact, I first participated in the research session, and only after that decided to join the company). I assume you're asking specifically about discussing telemetry and open source, not only the features. We try to be super open about collecting the data, and published an extensive list of things we report. Most of our users don't mind.…

Why did you not just make telemetry and logins opt-in? That avoids the entire issue from day one.

I think that's what is giving people a strange feeling about this. You prioritized your own desires (not needs mind you) rather than your users. And if your thinking is so off that you really think these are needs during the beta then that is even more worrying.

If I were in your shoes I'd crunch immediately to make telemetry, crash reporting, and logging in three separate opt-in features then get a build out ASAP. Prompt people to enable or disable each with clear language in a single screen (no EULAs or lawyer weasel words) and no dark patterns (like double-negative checkboxes or flipping cancel and accept button colors).

For crash reports and logins there is an even better way to handle this that is respectful of your users without being obtrusive and shows you are working hard to earn trust. Then you only need one post-install prompt to ask permission to share data which is much simpler.

1. Ask the user each time you find a crash report and let them inspect it if they want to do so, then ONLY send the content the user inspected (no hidden payloads, extra HTTP headers, etc). Include a checkbox/dropdown "Always send" or "Never send". The default is to ask the user to help you out. It gives transparency by letting them inspect the entire payload. And if/when you've earned their trust they will click Always on their own. It also covers you just in case the payload accidentally picks up something sensitive.

2. When the user invokes a feature that actually needs a login then prompt them at that time. Or if the context doesn't allow that, show an unobtrusive icon, link, or banner in a context-appropriate way that lets them create an account or login.

3. For sharing let users share things anonymously with links, no account required. Once they've started using the feature let them know they can create an account to "claim" the things they've shared. This can be a good way to show people the benefits rather than just claiming benefits exist. It makes a nice on-ramp without pestering or annoying people who never create an account. And the people they share things with may end up becoming your users.

Re: Show HN: Warp, a Rust-based terminal

#678
post #439
post #27

I've been loving Warp since discovering it on HN a few months back. I was originally drawn in by how it treats text input like a regular text input field out of the box, so I don't have to configure anything and my normal text editing shortcuts just work. 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 n…

Warp engineer here - Thanks for being an early user! 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 part…

Ctrl-x, ctrl-e

Re: Show HN: Warp, a Rust-based terminal

#679

This is bullshit. > The terminal’s teletype-like interface has made it hard for the CLI to thrive bullshit > user accounts to just run a terminal? bullshit > collaboration bullshit ...

Please contribute more elaborative criticism than simply the word "bullshit"

No post body was provided.

Re: Show HN: Warp, a Rust-based terminal

#680

Earlier quoted context omitted.

or 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...

> remove forced telemetry, remove sign-in in the next release Then why would anybody bother to invest in their next series?

because they have a growing number of paying customers.
Post reply on HN