realharo

On one hand, this is definitely a gap, on the other hand, you are very unlikely to run into it in practice.

The whole "pass an array/object into some function that will mutate it for you" pattern is not very popular in JS , you are much more likely to encounter code that just gives you a new array as a return value and treats its arguments as read-only.

If you validate your data at the boundaries where it enters your system (e.g. incoming JSON from HTTP responses), TypeScript is plenty good enough for almost all practical uses.

This may actually be one of those things where it turns out to be worth it (for them anyway), if they get some major technological advancements out of it.

There are so many other things in the world that are way more wasteful and way more pointless.

Ok, so Facebook knows I have a VR headset and bought some games, and they're using that information in targeted advertising (as much as things like EU law allows them where I live)? Quite frankly, I don't care - this doesn't really affect me in any practical sense - and again, thanks to existing laws, I can actually opt out from a large part of it.

From a practical standpoint, I would have a much bigger problem with a situation that exists with Google, where some people had access to their email and other services disabled, because some stupid bot classified their comments in YouTube livestream as spam with basically no recourse until the story blew up in tech news (https://gamerant.com/markiplier-stream-ban-lock-users-out-of-gmail/). The root of the issue there is that those accounts just shouldn't be linked, and what you do on YouTube shouldn't affect your access to your own email etc.

You may argue that this is simply down to the fact that Facebook doesn't have a strong enough market position to get away with such practices, and that they would do it too if they could, but as it stand today, the giants like Google or Apple are far worse. (And with most of these problems, as well as other monopolistic practices of tech giants, regulation can be a large part of the solution.)

Everything that has a store requires an account.

• Steam - you need Steam account (also applies to Valve Index then)
• iPhone - you need Apple account
• Android phones - you need Google account
• Oculus before - you needed an Oculus account

The short time during which they required a Facebook account (i.e. an account linked to an unrelated service) was a fuck-up, but they have since reversed that decision. Now it's just a separate standalone VR-related account.

If anything, that is still better than the current Google/Apple situation with their accounts, which link together a bunch of unrelated services (photos, email, payments, storage sync, etc.) in an inseparable way.

And housing, as usual.

But that's not the case here, seeing as they have

if self.len() >= MAX_STACK_ALLOCATION {
    return with_nix_path_allocating(self, f);
}

in the code of with_nix_path. And I think they still could've made it return the value instead of calling the passed in function, by using something like

enum NixPathValue {
    Short(MaybeUninitᐸ[u8; 1024]>, usize),
    Long(CString)
}

impl NixPathValue {
    fn as_c_str(＆self) -> ＆CStr {
        // ...

impl NixPath for [u8] {
    fn to_nix_path(＆self) -> ResultᐸNixPathValue> {
        // return Short(buf, self.len()) for short paths, and perform all checks here,
        // so that NixPathValue.as_c_str can then use CStr::from_bytes_with_nul_unchecked

But I don't know what performance implications that would have, and whether the difference would matter at all. Would there be an unnecessary copy? Would the compiler optimize it out? etc.

Also, from a maintainability standpoint, the context through which the library authors need to manually ensure all the unsafe code is used correctly would be slightly larger.

As a user of a library, I would still prefer all that over the nesting.

Most places have preorders open, shipping in October, also Pi 4s are now back in stock in most shops.

You can always get the Pi Zero 2 W, which is still more capable than the orignal Pi was, and costs even less, even after all these years.

Or the 1 GB version of the Pi 4. For many projects, even that is overkill. Not everyone needs the stuff Pi 5 brings, like dual 4k60 monitors or the PCIe slot.

Just buy whatever your use case requires. The "zero" line has kind of filled that very low cost niche for now.

I think the issue with this is that the code (https://docs.rs/nix/0.27.1/src/nix/lib.rs.html#297) allocates a fixed-size buffer on the stack in order to add a terminating zero to the end of the path copied into it. So it just gives you a reference into that buffer, which can't outlive the function call.

They do also have a with_nix_path_allocating function (https://docs.rs/nix/0.27.1/src/nix/lib.rs.html#332) that just gives you a CString that owns its buffer on the heap, so there must be some reason why they went this design. Maybe premature optimization? Maybe it actually makes a difference? 🤔

They could have just returned the buffer via some wrapper that owns it and has the as_cstr function on it, but that would have resulted in a copy, so I'm not sure if it would have still achieved what they are trying to achieve here. I wonder if they ran some benchmarks on all this stuff, or they're just writing what they think will be fast.