Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

github.com

Post reply on HN
Print view View original

251–260 of 390 posts

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#251

Post by jodrellblank »

inetknght wrote: post #188
nicce wrote: post #183

Earlier quoted context omitted.

Telemetry can be implemented well. The software you use gets bugs fixed much faster since you get statistics that some bugs have higher impact than others. The more users software has, less skills they have in average to accurately report any issues.

> The software you use gets bugs fixed much faster since you get statistics that some bugs have higher impact than others. Try talking to your users instead. > The more users software has, less skills they have in average to accurately report any issues. No amount of telemetry will solve that.

The PowerShell team at Microsoft added opt-out telemetry to track when it was launched so they could make the case internally that they should get more funding, and have more internal clout.

It’s easy to argue that if you are a PowerShell user or developer you benefit from no telemetry, but it’s hard to argue that you benefit from the tool you use being sidelined or defunded because corporate thinks nobody uses it. “Talk to your users” doesn’t solve this because there are millions of computers running scripts and no way to know who they are or contact them even if you could contact that many people, and they would not remember how often they launched it.

https://learn.microsoft.com/en-us/powershell/module/microsof...

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#252

Post by duped »

dmitrygr wrote: post #52

I remind you, again, that vi, gcc, as, ld, and make have no telemetry, launch few (if any) processes, do not need GB of RAM, and work well.

gcc/as/ld are batch processors from the GNU toolchain that offer few (if any) features beyond basic C/C++ (and a handful of other languages) as support, and they're non-standard toolchains on 2 out of 3 major operating systems requiring a bit of heavy lifting to use.

It's kind of nonsense to bring them up in this conversation.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#253

Post by firesteelrain »

dotancohen wrote: post #88
neuroelectron wrote: post #49

VSCode is extremely unsafe and you should only use it in a managed, corporate environment where breaches aren't your problem. This goes with any fork, as well.

What should I be reading to know more about this? I am considering a move from Jetbrain's products to VS Code.

If you are US and trust US products then consider moving away from Jetbrains to VS Code

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#254

Post by kiitos »

In the OP screen share, they toggle various telemetry options on and off, but every time a setting changes, there is a pop-up that says "a setting has changed that requires a restart [of the editor] to take effect" -- and the user just hits "cancel" and doesn't restart the editor. Then, unsurprisingly, the observed behavior doesn't change. Maybe I'm dumb and/or restarting the editor doesn't actually make a difference, but at least superficially, I'm not sure you can draw useful conclusions from this kind of testing...

edit: to be clear I see that they X-out the topmost window of the editor and then re-launch from the bottom bar, but it's not obvious that this is actually restarting the stuff that matters

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#255

Post by Aurornis »

kiitos wrote: post #254

In the OP screen share, they toggle various telemetry options on and off, but every time a setting changes, there is a pop-up that says "a setting has changed that requires a restart [of the editor] to take effect" -- and the user just hits "cancel" and doesn't restart the editor. Then, unsurprisingly, the observed behavior doesn't change. Maybe I'm dumb and/or restarting the editor doesn't actually make a difference…

Thanks for watching and catching that. It seems like a major oversight for the core claim: That disabling telemetry doesn’t work. If a restart is required and the tests ignored the restart warning that would invalidate the tests.

Either way, it’s useful to see the telemetry payloads.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#256

Post by macintux »

ragequittah wrote: post #250
macintux wrote: post #226

Earlier quoted context omitted.

I always want the choice to be mine. I was interested in learning Dart until the installer told me Google would be collecting telemetry. For a programming language. I’ve never looked at it again.

As a somewhat paranoid person I find this level of paranoia beyond me. Like do you own a car? Or a phone? A credit card? Walk around in public where there's cameras on every block? I don't agree with it at all but the world we're living it makes it impossible to not be tracked with way more than (usually anonymized) telemetry data.

I'm aware I'm being tracked all the time. That doesn't mean I have to encourage more of it.

We all pick our own battles.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#257

Post by leetbulb »

I wonder how many of these telemetry events can sneakily exfiltrate arbitrary data like source code. For example, they could encode arbitrary data into span IDs, timestamps (millisecond and nanosecond components), or other per-event UIDs. It may be slow...but surely it's possible.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#258

Post by segfault22 »

kiitos wrote: post #254

In the OP screen share, they toggle various telemetry options on and off, but every time a setting changes, there is a pop-up that says "a setting has changed that requires a restart [of the editor] to take effect" -- and the user just hits "cancel" and doesn't restart the editor. Then, unsurprisingly, the observed behavior doesn't change. Maybe I'm dumb and/or restarting the editor doesn't actually make a difference…

Tested both ways, telemetry stays the same, the prompt is to restart IDE but i wanted to disable both Telemetry options before i do it.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#259

Post by drewbitt »

andylynch wrote: post #180
fHr wrote: post #157

Earlier quoted context omitted.

eclipse still is alive holy shit

Installing the VSCode extension pack for Java runs a headless version of Eclipse JDT under the hood, which isn’t quite what I think of as lightweight.

You can set the launchMode to LightWeight which spins up a syntax-only language server.

Re: Performance and telemetry analysis of Trae IDE, ByteDance's VSCode fork

#260

Post by Eisenstein »

jodrellblank wrote: post #251
inetknght wrote: post #188

Earlier quoted context omitted.

> The software you use gets bugs fixed much faster since you get statistics that some bugs have higher impact than others. Try talking to your users instead. > The more users software has, less skills they have in average to accurately report any issues. No amount of telemetry will solve that.

The PowerShell team at Microsoft added opt-out telemetry to track when it was launched so they could make the case internally that they should get more funding, and have more internal clout. It’s easy to argue that if you are a PowerShell user or developer you benefit from no telemetry, but it’s hard to argue that you benefit from the tool you use being sidelined or defunded because corporate thinks nobody uses it. “…

To take that logic to its extreme: I'm sure we could have amazing medical breakthroughs if we just gave up that pesky 'don't experiment on non-consenting humans' hang-up we have.
Post reply on HN