It is not a good idea, especially with the new chiplet/CCX processors.

I was using a dell S3225QC with 120 hz and even variable rate with macbook m1 pro. No hdr with 120 or variable rate though, only at 60.

Systemd is just another init system. People said the same thing about how it can exist with other ones in a level playing field.

By the virtue of having some motivated backers, not only they have pushed everyone out from any distro which matters or acts as a root for others, they have formed a neat little company called Amutable which produces tech allowing anyone to lockdown any installation to an immutable, untouchable state.

Yeap, systemd is just another init system existing on a level playing field. They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.

> They just dare to be successful by tackling problems that people have today over trying to deliver solutions designed in 1989.

Thanks for your input. Can you please elaborate about these problems a bit more? I'm pretty new on this Linux thing. Using for just 20 years or so, and managing a quite a few hundred servers only. systemd didn't make my life drastically different or smoother.

Oh, I also used to be a tech-lead of a Debian derivative, and also did some country-wide rollouts of the thing we developed, but I'm sure it has no addition to my already extremely limited knowledge of how things work.

Maybe this is because I'm a noob, or not using enough machines, or not have enough downtime, IDK.

Any info will be greatly appreciated, thanks.

I wanted to check the hype, so I installed Zed and opened a go project.

Ram usage:

VS Code 580 MB

Zed 410 MB

I don't see a reason yet to switch away from VS Code, more feature complete and I don't care about scroll speed, it's good enough in vs code.

How much of the RAM usage is by gopls (The Go LSP)?

Kind of there with you... was pretty surprised how big the surface was with Zed, and it definitely doesn't do all the things I do in Code currently.

Try Sublime Text if you want lower RAM usage. My instance is currently sitting at ~120mb with 3 separate projects open (that does not include usage by Rust Analyzer which runs in a separate process (and tends to use GBs of RAM), but I suspect your numbers don't either)

Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what.

I dont understand the zed hype, not only the UI has tons of issues, memory usage is not that different

> Last time I used zed for go development it spawned nodejs servers (downloaded without asking for permission!) for god knows what.

LSPs, they are snagging the LSPs made by other developers for languages you are using. if you install any LSP or language support in VSCode its running the same thing. It only installs when you are using a language that has default support such as Rust, Python (which I believe uses a Node.js LSP), Go (same as Python), etc.

So basically there is no getting away from javascript runtime. So why should I use zed instead of vscode then?

Latency, FPS, efficiency. The LSPs while beefy, are not part of the overall efficiency and are used as sub processes, so if they fail or are sluggish, they won't affect how the editor runs, if you don't want to use LSPs, then you can go ahead and disable those.

Zed is one of the few editors, that like Sublime, are really focused on efficiency, using minimal resources (when needed) and the latency and FPS of the editor is bounds better than VS Code. It just works, better.

what about CPU usage? Overall I agree, it doesn't have enough plugins and is not well supported yet.

Currently Zed uses more CPU than VSCode on my Windows and macOS laptops.

I don't know what's going on in this thread. Of course PKI needs some root of trust. That root HAS to be predefined. What do people think all the browsers are doing?

Lineage is signed, sure. It needs to be blessed with that root for it to work on that device.

They're assuming PKI is built on a fixed set of root CAs. That's not the case, as others have pointed out - only for major browsers. Subtle nuance, but their shitty, arrogant tone made me not want to elaborate.

"Subtle nuance" he says, after I've spent multiple comments explaining that bootloaders reject unsigned and untrusted-signed code identically, whilst he and others insist there's some meaningful technical distinction (which none of you have articulated).

Then you admit you actually understood this the entire time, but my tone put you off elaborating.

So you watched this thread pile on someone for being technically correct, said nothing of substance, and now reveal you knew they were right all along but simply chose not to contribute because you didn't like how they said it.

That's not you taking the high road, mate. That's you admitting you prioritised posturing over clarity, then got smug about it.

Brilliant contribution. Really moved the discourse forward there.

You seem angry. Perhaps some time away from the message boards would be beneficial.

Still not elaborating on that "subtle nuance," I see.

Right, now what would you say is the probability of getting a bug in compiler output vs ai output?

It's a great tool, once it matures.

I am not getting what that linked url is supposed to mean. It is a very decent business page where ubuntu is selling consulting for "your" projects and telling why ubuntu is great for developing AI systems.

I hope for our (India's) sake, it doesn't. We need to keep as much talent here as we can.

It's cheapest for the employer to keep it in India itself.

That would make sense if protobuf was complex, bloated, slow. But it's not, so the question should be why not use it, unless you are doing browser stuff.

If you are going to use it elsewhere, why not use it for browser stuff too?

I would advise against it. Too much friction, try it, maybe you will have a different experience than mine.

I am curious about what kind of friction you encountered. Were you generating ad-hoc protobuf messages?

Assuming you were using Protobufs as they are usually used, meaning under generated code, I saw no difference between using it in Javascript and any other language in my experience. The wire format is beyond your concern. At least it is no more of your concern than it is in any other environment.

There are a number of different generator implementations for Javascript/Typescript. Some of them have some peculiar design choices. Is that where you found issue? I would certainly agree with that, but others aren't so bad. That doesn't really have anything to do with the browser, though. You'd have the same problem using protobufs under Node.js.

Every time I hear any Indian trope, I find it interesting that it's only people in online forum who experience it.

Somehow none of my non/Indian colleagues over the course of more than a decade have faced these ridiculous situations. They must be unlucky.

Many wouldn't be comfortable discussing this with coworkers.