5 ms·
We started with macOS because I have a background in Swift development. Linux is definitely not an after thought to us! As for the telemetry concerns, I totall
by mschrage 5y ago
We started with macOS because I have a background in Swift development. Linux is definitely not an after thought to us!
As for the telemetry concerns, I totally get that. We've tried to strike a balance and it seems like we've got it wrong. This will be fixed in the next update.
- sidlls 5y agoThe correct balance is 0% of terminal activity is sent with telemetry, unless the user explicitly and specifically authorizes it.
- mschrage 5y agoJust to clarify, the text you type into the terminal NEVER leaves your device. Fig does not store or collect this information. We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app. We also send which completion spec (eg. git, npm or cd) was used to generate the suggestions to know which commands to prioritize.
- sidlls 5y agoA distinction without difference, in my opinion. And it doesn't change the fact that anything other than 0% telemetry without full, complete disclosure and permission from the user is not good.
- smoldesu 5y agoSo wait a second, the text I type into the terminal never leaves my device, but the commands I invoke do? What's the difference?
- rabidrat 5y agoYeah just don't accidentally paste your password into a terminal and press Enter.
- sidlls 5y agoI don't know if that's a fair reading of the functionality. It seems likely your mistakenly pasted password will generate an autocomplete and the (mis-)matched "spec" command will be sent as the telemetry, e.g., pasting "gi)#(RCS23!_)(U" into your terminal might result in "git" telemetry, not the password itself. It's one of those things that is just trivial to introduce breaking changes to, though, intentionally or otherwise. And as-is the functionality does share what amounts to the terminal activity in normal cases.
- mbreese 5y ago>We send an event when you insert something using Fig's autocomplete, so we can get a sense for how frequently people use the app And this is why you're never going to get people to use it. I get that you want to know what is being used, but really -- this is a terminal. You can't have any kind of telemetry for a terminal. If you had a very big notice when you install, asking for permission to send which commands get autocompleted, you'd have likely been in a better position. Debian does something like this on install -- asking permission to track what packages you've installed. But it very clearly optional. And their level of knowledge is just that a package was installed, not necessarily how frequently it it used. Anything approaching telemetry within a terminal is just a bad idea. And I fail to see how you couldn't also get the same data from surveys, features requests, issue tracking, etc... It wouldn't be the same quality, but this is really really bad. And because you started out with this major faux pas, you're going to have a major problem with trust going forward.
- smoldesu 5y ago+1 for this. I don't wanna be rude, but dataops isn't a joke: I'm not going to put my security into the hands of someone who already made egregious security oversights an integral part of their product.
- ljm 5y ago> generate the suggestions to know which commands to prioritize What does 'prioritize' mean in this context? Other completion tools (like fasd) write command history to a local dotfile so they can build up knowledge of 'frecency'. This makes sense, it's no different to your ~/.bash_history file really. I wouldn't trust any single tool that tried to build a parallel history through an analytics integration. Fig claims that it 'loads up once then remains entirely local', though, and it's adorned with an icon that suggests it remains offline. What you're saying here seems to contradict that. If the tool is entirely local/offline, how is it phoning home with the commands you type? And does it send along the arguments you pass to the command if you happened to complete them?
- dheera 5y agoJust add "0.0.0.0 fig.io" (or whatever it is, wireshark it to find out) to your /etc/hosts
- heyoni 5y agoDoesn’t it auto update? That’s a cat and mouse game I wouldn’t want to play.
- Cyberdog 5y ago> I have a background in Swift development. Then why on earth did you go out of the way to implement this in JavaScript instead?
- mschrage 5y agoThe current implementation of Fig is a native macOS app (Swift/ObjC) that exposes an API to access terminal specific information - edit buffer, working directory, current process, etc. On every platform we support, we'll implement this natively. As Fig grows, we want to enable an ecosystem of UI extensions for the terminal that are built to go cross platform. Using web technology here made sense since we can leverage built-in webviews for rendering or bundle a lightweight implementation like Tauri[0]. [1]
- Cyberdog 5y agoI don't understand this response, so let me rephrase my question. This page https://fig.io/docs/getting-started https://fig.io/docs/getting-started says that Node.js and NPM is required to use Fig. I presumed this meant that Fig was written in JavaScript, but you're saying it's native. Then why is Node required? If you're using web views for UI, wouldn't those web views on each respective platform already have their own JS engines?
- tasuki 5y ago> Linux is definitely not an after thought to us! Care to share more about this? Which terminals are you planning to support?