ChrisSD

Huh, I've been using Zed for awhile now and never even noticed it until you mentioned it. Fortunately there's a setting to remove it.

Do you have plans for handling C FFI without "unsafe"? Will it require some sort of extension module written in C/C++/Rust?

Why do you feel uncomfortable? Why do you think anyone is trying to make you feel uncomfortable?

It's ok to be strange. It's ok to be bizarre. Be free.

I do not understand the desire for everybody else in the world to act exactly like you. Variety is the spice of life.

For sure, there are other hardware requirements a 2017 CPU may fail.

It's beside the point of the article but...

> The hardware limitation is specifically TPM 2.0

Almost every even half decent CPU made in the last decade does have TPM 2.0, albeit for some strange reason OEMs used to ship with it disabled. You may be able to turn it on in the bios.

To be clear, Ubuntu did nothing. This is a third party implementation that Ubuntu decided to ship in their OS.

That study only says that most Americans think they interact with AI at least a few times a week (it doesn't say how or if it's intentional). And it also says the vast majority feel they have little or no control over whether AI is used in the lives.

For example, someone getting a google search result containing an AI response is technically interacting with AI but not necessarily making use of its response or even wanting to see it in the first place. Or perhaps someone suspects their insurance premiums were decided by AI (whether that's true or not). Or customer service that requires you go through a chat bot before you get real service.

Windows also has uuids. E.g.:

    \\.\Volume{3558506b-6ae4-11eb-8698-806e6f6e6963}\

They're using slide rule users as a stand-in for serious mathematician as opposed to people who incidentally use mathematics. It makes some sense in historical context but becomes a bit anachronistic after the invention of electronic calculators.

^_^ sucks when you actually need to talk about emoji though :/

Tbh, the rights and wrongs aside, I suspect "everyone" is complaining about it because it's the easiest thing to talk about. Much like how feature discussions tend towards bikeshedding.

That's an entirely different issue. The kb's of overhead for backtrace printing and the format machinery is fixed and does not grow with the binary size. All combined it wouldn't account for anywhere close to 1mb let alone 100's of mb.

Tbh I really don't think it matters what the letters stand for.

That sounds like they were mandated to shoehorn "AI" into their description in some way. Because it is indeed a non sequitur.

More or less, yes. It is guaranteed that tier 2 at least builds so they'll be a nightly available every day though it's possible they might have a serious bug. To be honest though that's always a risk for nightlies even with tier 1 targets. Tests don't catch every potential problem (even if they do catch a lot) which is why there is a beta period before a release.

To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3.

Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.

In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant.

I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.

huh?

I think the two basic synchronisation primitives are atomics and thread parking. Atomics allow you to share data between two or more concurrently running threads whereas parking allows you to control which threads are running concurrently. Whatever low-level primitives the OS provides (such as futexes) is more an implementation detail.

I would tentatively make the claim that channels (in the abstract) are at heart an interface rather than a type of synchronisation per se. They can be implemented using Mutexes, pure atomics (if each message is a single integer) or any number of different ways.

Of course, any specific implementation of a channel will have trade-offs. Some more so than others.

A safe API would look a lot like Windows' GetEnvironmentVariable and SetEnvironmentVariable

https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

It can only synchronize if everything using is Rust's functions. But that's not a given. People can use C libraries (especially libc) which won't be aware of Rust's locks. Or they could even use a high level runtime with its own locking but then they'll be distinct from Rust's locks.

The only way to coordinate locking would be to do so in libc itself.

In the Rust std, `set_var` and `remove_var` will correctly require using an `unsafe {}` block in the next edition (2024). The documentation does now mention the safety issue but obviously it was a mistake to make these functions safe originally (albeit a mistake even higher level languages have made).

https://doc.rust-lang.org/stable/std/env/fn.set_var.html

There is a patch for glibc which makes `getenv` safe in more cases where the environment is modified but C still allows direct access to the environ so it can't be completely safe in the face of modification https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6f...

No but it doesn't use C library values so it doesn't matter. E.g. getting the command line arguments is done via calling `GetCommandLineW` so it doesn't use argv or argc.

This is actually necessary because Rust cannot assume it owns the entry point. E.g. a Rust library could be called from a C++ application or in a DLL, etc. So when someone calls `std::env::args` it asks the OS directly for the arguments instead of getting them from C.

That's the "vcruntime" not the "ucrt". There has been a distinction since the ucrt was made an official part of the OS.

It's very easy to make a win32 program without the ucrt filesytems APIs so long as you don't mind being platform-specific (or making your own cross-platform wrappers).

Rust's standard library basically never uses ANSI APIs. The article doesn't demonstrate any attack that works against Rust. If they do have one I'd highly recommend reporting it.

Of course, Rust can't control what happens on the other side of side of a process boundary. So if an application invoked by Rust uses ANSI APIs then they'll have a problem. But also that's their responsibility.

Rust 1.0 was released in 2015 making it almost ten years old.

Rust, unlike Go, was largely developed in public. It also changed significantly between it's initial design and 1.0 so it feels like "cheating" to count pre-release versions.

Still, a decade is a significant milestone.

> Some can try

Rust does this with standard types even. "Parse, don't validate" is the answer to the question: why does Rust have so many string types? Of course you can hack around this using `unsafe` but, as you say, in that case you have to put visible effort into deliberately subverting the type system.

The usual complaint is that there has been little progress on async and webdev in Rust itself since 2018 so it's odd to hear the reverse complaint.

Though I would add that Rust's async is not just about webdev; it has had success in embedded contexts e.g. the popular https://github.com/embassy-rs/embassy?tab=readme-ov-file#emb...

On Pro it would be better to use the group policy editor. As a bonus this also ensures the setting survives updates, which is not always a given for raw registry edits.