Arnavion

>This dance to get access is just a minor annoyance for me, but I question how it proves I’m not a bot. These steps can be trivially and cheaply automated.

>I think the end result is just an internet resource I need is a little harder to access, and we have to waste a small amount of energy.

No need to mimic the actual challenge process. Just change your user agent to not have "Mozilla" in it; Anubis only serves you the challenge if it has that. For myself I just made a sideloaded browser extension to override the UA header for the handful of websites I visit that use Anubis, including those two kernel.org domains.

(Why do I do it? For most of them I don't enable JS or cookies for so the challenge wouldn't pass anyway. For the ones that I do enable JS or cookies for, various self-hosted gitlab instances, I don't consent to my electricity being used for this any more than if it was mining Monero or something.)

Oh I see.

systemd's method does not require the service process to have access to the original creds file, or even the filesystem that contains it. In fact the original credentials file might even be an encrypted file and the key (and/or hardware) to decrypt it does not need to be accessible to the service process.

Yes, C#'s DSL that compiles to SQL (LINQ-to-SQL) does the same thing, `from` before the other clauses, for the same reason that it allows the IDE code completion to offer fields while typing the other clauses.

>Just an example of systemd limitation is that systemd does not support musl, so if you want to build a tiny embedded sysroot, you already have some limitations.

OpenEmbedded has carried a patchset to build systemd against musl for use in Yocto for a long time.

postmarketOS already got approval from Poettering to make a musl-linked systemd more officially supported.

You can do it with an NS record, ie _acme_challenge.realdomain.com pointing to the DNS server that you can program to serve the challenge response. No need to make a CNAME and involve an additional domain in the middle.

It is also how RISC-V floating point registers are required to store floats of smaller widths. Eg if your CPU supports 64-bit floats (D extension), its FPU registers will be 64-bit wide. If you use an instruction to load a 16-bit float (Zfh extension) into such a register, it will be boxed into a negative quiet NaN with all bits above the lower 16 bits set to 1.

Could be a monitor with a mini PC on the back.

I stand corrected. I didn't know rustc supported such a coercion automatically. Now I see it is documented in CoerceUnsized + Unsize.

That said, other than the problem of this being a breaking API change for Read::read_to_end, another problem is that Vec's layout is { RawVec, len } and the allocator is inside RawVec, so the allocator is not the last field of Vec, which is required for structs to contain unsized fields. It would require reordering Vec's fields to { len, RawVec } which may not be something libstd wants to do (since it'll make data ptr access have an offset from Vec ptr), or to inline RawVec into Vec as { ptr, cap, len, allocator }.

>No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370

The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.

It's also not a wasted skill. Once you've learned how to `git send-email` for the sake of one project, you're now prepared to do the same for others.

First of all, `dyn Vec` is impossible. Vec is a concrete type, not a trait. I assume you meant `Vec<u8, dyn Allocator>`.

Second, no a `&mut Vec<u8, A>` is not convertible to `&mut Vec<u8, dyn Allocator>`. This kind of unsized coercion cannot work because it'll require a whole different Vec to be constructed, one which has an `allocator: dyn Allocator` field (which is unsized, and thus makes the Vec unsized) instead of an `allocator: A` field. The unsized coercion you're thinking of is for converting trait object references to unsized trait object references; here we're talking about a field behind a reference.

The article is about how and why mixing allocators fails, not if it fails or how to fix the problem.

>But with the upcoming support for passing an allocator to any data structure (in the Rust standard library anyway) I think this gets a lot easier?

Yes and no. Even within libstd, some things require A=GlobalAlloc, eg `std::io::Read::read_to_end(&mut Vec<u8>)` will only accept Vec<u8, GlobalAlloc>. It cannot be changed to work with Vec<u8, A> because that change would make it not dyn-compatible (nee "object-safe").

And as you said it will cut you off from much of the third-party crates ecosystem that also assumes A=GlobalAlloc.

But if the subset of libstd you need supports A=!GlobalAlloc then yes it's helpful.

I don't know what examples you've been seeing. The interop structs are just regular Rust structs with the `#[repr(C)]` attribute applied to them, to ensure that the Rust compiler lays the struct out exactly as the C compiler for that target ABI would. Rust code can access their fields just fine. There's no strict need for accessor functions.

I see. I've never had to deal with any Option ROMs myself. In that case the easier option is to add their hash to db?

`fn partition[T: ...]` uses `[]` to define T. `s: Slice(T)` uses `(T)` to invoke the type constructor `Slice` with the type argument T. So you could say that's fine because these are different operations.

But then defining a type constructor itself still uses `()`, like `class UnsafeAllowDelete(T:! Concrete) { ... }`. It does seem somewhat inconsistent.

There is also the option of enrolling your own certs and resigning the bootloader and any Option ROMs you need, if you're really worried / expect to actually be broken by this.

The reason Rust doesn't have those things in libstd is because it doesn't want to commit to backward compatibility for them. Note that Rust is 1.0 and has no plans to switch to 2.0.

Zig will presumably have the same care about backward compatibility once it becomes stable.

There isn't anything fundamental about Zig that makes it immune from package explosion. It simply isn't popular and stable enough for that to have happened yet.

>> 9. the end-to-end encryption is also annoyingly fragile

>Not any more; we fixed it over the course of 2024 [...] If anyone sees Unable To Decrypt messages these days (at least on Element Web or Element X + Synapse) we need to know about it.

You haven't "fixed" anything. I just opened Element X to an E2EE room hosted on a Synapse server, and I see a dozen "Waiting for this message"'s from three different people. Half the conversation in this room is people saying so-and-so's messages are unreadable, and of course it's a different person for everyone. Another client I have can see those people's messages, presumably because it was online at the time those people's clients joined / rotated their keys, because Matrix E2EE apparently depends on all parties' clients being online at the same time to be able to share keys.

This is exactly how it's been for years, in multiple rooms and clients, so it's hard to believe anything's changed, let alone been fixed.

The same thing happens with Element Web too, but at least that supports manually exporting and importing keys so that I can manually union all the working keys between all the clients. But of course Element X doesn't support that feature.

Just an idea. In my SwayWM setup, a) I run every application in its own cgroup (via systemd-run), and b) I have a daemon that subscribes to window and workspace events, gets the current tree, figures out the PIDs corresponding to invisible vs visible windows, figures out the cgroups corresponding to those PIDs, and then uses cgroup freezer file to freeze / unfreeze them. Other than a few hard-coded exceptions that I want to run while invisible (IRC client etc), any invisible application is transparently frozen and unfrozen.

For "single-instance applications" like firefox, launching a new firefox while the existing one is frozen will hang, so instead of launching /usr/bin/firefox directory I have an intermediate ~/.local/bin/firefox script that unfreezes the firefox cgroup and then exec's /usr/bin/firefox.

Of course if at least one FF window is visible then this doesn't help with your problem, since the cgroup as a whole will be unfrozen. It only helps if none of the FF windows are visible.

Proc macros themselves are slow too. If you compile them in debug mode, they run slowly. If you compile them in release mode, they run faster but take longer to compile. This is especially noticeable with behemoth macros like serde that use the complicated syn parser.

Compiling them in release mode does have an advantage if the proc macro is used a lot in your dep tree, since the faster invocations compensate for the increased compile time. Another option is shipping pre-compiled macros like the serde maintainer tried to do at one point, but there was sufficient (justified) backlash to shipping blobs in that case that it will probably never take off.

Here's a comparison of using serde proc macros for (De)Serialize impls vs pre-generated impls: https://github.com/Arnavion/k8s-openapi/issues/4#issuecommen... In other words the amount of code that is compiled in the end is the same; the time difference is entirely because of proc macro invocation. 5m -> 3m for debug builds, 3.5m -> 3m for release builds. It's from 2018, but the situation is largely unchanged as of today.

>It's not great, but you can't expect people to fix everything, especially for fairly minor issues like this.

1. It's not a minor issue that a privacy feature doesn't work.

2. OP clearly stated ( https://gitlab.gnome.org/GNOME/evolution/-/issues/3095#note_... ) that they know the fixes are not trivial, so at the very least they want the application and website to make it clear that the privacy feature doesn't work, so that users are not misled.

Stacked borrows is miri's runtime model. Run it under miri and you will see the error reported for the `*x = 10;` version but not the `write(x);` version - "Undefined Behavior: attempting a write access using [...] but that tag does not exist in the borrow stack for this location".

rustc itself has no reason to reject either version, because y is a *mut and thus has no borrow/lifetime relation to the &mut that x is, from a compile-time/typesystem perspective.

The * value is the result of converting 10 miles to meters, as requested.

The / value is the inverse of that in case you wanted that, ie 0.1 meters in miles.

It's explained in `man 1 units`

>Have you actually ever encountered such a bug in tmux though? Because I've been using it for around 15 years and can honestly say I haven't.

Since you asked, once every few months or so the whole server crashes which takes out all my windows. I don't know what exactly triggers it, other than it being something to do with pasting, and it's so infrequent that I haven't bothered to investigate it. Obviously the trivial repro of just pasting the same thing I tried to paste the first time doesn't repro it; I'd need to gdb the coredump, which is :effort:

I wouldn't expect this Rust rewrite or any other rewrite to fix it in any case; it would be more efficient to figure out the crash and fix it in the original C version.

The article says to use the "XOR of all elements" method to find u^v, then do the partitioning, then use the "XOR of all elements" method on the first partition to find u, then use the "XOR of all elements" method on the second partition to find v.

tromp is saying the last step can be simplified. There is no need to use the "XOR of all elements" method on the second partition to find v, since the earlier steps have given us u^v and u, so simply XORing those two values together gives v.

Even with the original formulation, the array doesn't have to fit in available memory. mmap exists.

It doesn't matter. Overflow is a non-issue as long as you have wrapping addition and subtraction operators, which C# does - regular `+` and `-` not inside `checked {}`. You don't need to reach for BigInteger.