I am excited to announce that, as of today, Fig is generally available to the public for download.
With our public launch, I’d like to share a little more about Fig’s mission: who we are, what we’re doing, and what’s to come.
The terminal has barely changed since the 1970s and yet is still used every day by tens of millions of developers. Our bet is that the terminal isn’t going away any time soon. We are excited for Fig to play a part in its evolution.
Fig makes the terminal easier for beginners, more productive for advanced engineers, and more collaborative for teams.
To do this we are creating the app ecosystem for the terminal. We’ve built out a simple Javascript API (Fig.js) that makes it easy to extend your local terminal & shell with visual apps and shortcuts.
The first app built on top of the Fig platform is autocomplete. We are launching autocomplete today, but soon, we will open up our API so anyone can create their own apps.
Read in full here:
This thread was posted by one of our members via one of our news source trackers.
I’m… unsure what this even is actually? Not a terminal? Not a shell? What is it? And there’s no way to get it? Annoying closed-source hidden development, lol.
Well, I’ve given Fig a shot and it’s like autosuggestions from VSCode inside the terminal. In my case, it’s iTerm 2. It works like a charm, I guess it’s a virtual terminal on top of the original one because it asks for Accessibility authorization.
There is 2 Github repo inside the fig organization. It seems to be open-source stuff. Didn’t dig deeper, to be honest. I’ll try it for the next couple of days and see if I’ll keep it.
Yeah that’s linked above, but there’s no download there, and the github link only has source for the autocomplete plugin (which I’m curious how it can possible work without shell interactions?), not for fig?
There’s a “ Download for free” button on the landing page, but it’s written that at this moment, Fig only works on the Apple platform. Terminal, iTerm, Hyper and VSCode built-in terminal.
As I mentioned above, I guess it’s a virtual layer on top of the terminal and it uses the macOS Accessibility feature to manipulate the underlying terminal.
I tend to trust macOS because the application needs to ask for this kind of permission. And only after being granted, they can leverage some additional rights.
But it’s probably a bad habit
But once you allow something like accessibility access then what stops it from doing anything it wants ‘within’ that access? Because being allowed to read passwords and things like that sounds utterly horrible for security, especially when it should NOT need that access to begin with!
I tend to not trust by default, but then again I work at a college and I see a whole ton of fishy things happen, lol. But yeah, source MUST be available, even if not properly ‘open source’, the source must still be available and compileable so I can make my own binary from code that I can directly view. Anything else is just nicely inviting any such thing onto my system to unfettered password/key/whatever access without checking what it does with it first.
Closed source ‘might’ be fine (if not preferable) on things that don’t need any kind of access so I can safely run them sandboxed, but access to being able to read my inputs unfettered and being able to display random things like that is absolutely no-go without my own verification.
Whenever a password is asked, macOS uses a security feature called Secure Input.
Secure input is a macOS security feature that can be enabled & disabled by any app. Usually, this is used while password fields are active in order to prevent other apps from logging sensitive data.
I also use LuLu which is a FOSS version of Little Snitch to track any ongoing and outgoing network call of my machine. And if it looks suspect, I delete the responsible software.