Have enough developers really been conditioned to accept surveillance and pervasive centralized control that someone thought this was a good idea? The fact that the telemetry code even exists is a problem - both in case of a bug that turns it on, and what it says about the proclivities of its developers.
It's utterly inappropriate to refer to this as "the Rust-based terminal", as if the language is its distinguishing feature. More like "the obscene SaaSification of a basic foundational utility". I'd be very much interested in trying a new terminal written in Rust, which could presumably be quicker and have a smaller chance of hiding latent parsing bugs, but this most certainly is not that.
This is a enterprise product, and I can easily see how its adoption can save an organization a lot of time.
Easily share out custom workflows to fetch development keys and login to different services. Onboarding scripts that setup all the terminal things needed for development environment.
> "the obscene SaaSification of a basic foundational utility"
Watching their demo vid, it is a very nice terminal that also supports org wide shared scripts, in a unified manner with autocomplete.
Right now I have a text file with commands that I copy and paste daily to get things done. I share bits and pieces of this file with new hires when they onboard to solve various common problems. This shell solves that problem for an entire organization, and it does so in a discoverable way.
Can an org have their own repo of shell scripts? Sure, but then you have to make sure all developers in the org pull the latest when changes happen, and discoverability within "folder full of scripts" isn't the best.
> The fact that the telemetry code even exists is a problem - both in case of a bug that turns it on, and what it says about the proclivities of its developers.
Telemetry exists because running user studies is expensive. "What features are people using, what is crashing, where are people getting frustrated".
Yup the new script kiddies in town have not had to win wars against large enterprise companies.
Hacker culture is very minimal these days.
Now a quick npm install here and there, using a slow af editor like vs code, using autocomplete which sends your strokes to the sky and using every single cloud service available to be "pragmatic" while sipping soy lattes, have made this whole industry, slow, uncool and boring.
Same thing with the underlying business case for Intel/AMD's ME/PSP backdoors, and locked down computing in general. Yet we all now have to suffer their existence on every performant CPU made in the past decade.
If software developers had a professional oath to do no harm akin to doctors, creating such systems would be professional malpractice. Some lines just shouldn't be crossed.
>If software developers had a professional oath to do no harm akin to doctors, creating such systems would be professional malpractice. Some lines just shouldn't be crossed.
Being able to set up a quake mode reliably with assigning a key. I never got this working in iTerm2 in a way where the terminal would always pop up and have focus, despite having spent really lot of time in preferences creating profiles etc.
Seriously, what's wrong with you, iTerm2? Feel free to keep your multilevel settings, but expose the important stuff up front as a single click preset to apply.
I didn't know about Juicero, so for those who don't, this is hilarious:
> Juicero was an American company that designed and manufactured the Juicero Press, a fruit and vegetable juicer. The Juicero Press was a Wi-Fi connected juicer that used proprietary, single-serving packets of pre-chopped fruits and vegetables that were sold exclusively by the company by subscription. From 2014 to 2017, the San Francisco-based firm received $120 million in startup venture capital from investors.[1]
> The company attracted significant negative media attention when consumers and journalists discovered that its juice packets could be squeezed just as easily by hand as by the company's expensive machine. On September 1, 2017, the company announced that it was suspending sales of the juicer and the packets, repurchasing the juicer from its customers and searching for a buyer for the company and its intellectual property.[2][3] After its collapse, the company was described in the press as a symbol of a dysfunctional Silicon Valley culture. The Guardian wrote that Juicero was an example of "the absurd Silicon Valley startup industry that raises huge sums of money for solutions to non-problems."
There's another dimension to this story: the machine itself was so over-engineered [1] it was like using Kubernetes to host a static site with a single HTML file.
They had CNC machined parts when they had the capital to injection mold everything (they could have used exotic alloys and it still would have been cheaper), complex multi-material plastic parts, and the whole thing was way too complicated - the door lock alone had dozens of parts in an assembly controlled by a dedicated PCB.
Have enough developers really been conditioned to accept surveillance and pervasive centralized control that someone thought this was a good idea? The fact that the telemetry code even exists is a problem - both in case of a bug that turns it on, and what it says about the proclivities of its developers.
It's utterly inappropriate to refer to this as "the Rust-based terminal", as if the language is its distinguishing feature. More like "the obscene SaaSification of a basic foundational utility". I'd be very much interested in trying a new terminal written in Rust, which could presumably be quicker and have a smaller chance of hiding latent parsing bugs, but this most certainly is not that.