Arnavion

I do this with a WebDAV server (Fastmail Files) by breaking up my encrypted volume into 10MiB chunks, so that the sync has the granularity of that, plus a FUSE script to present the directory containing the chunks as a single block device for mounting. Obviously not cross-platform though.

>[Updated on 2025-09-09 to clarify the affected builds are 32-bit x86]

That's nice... When this was originally posted on 09-05 it just mentioned "32-bit support", so I'd been worried this would be the end of me using FF on a Microsoft Surface RT (armv7, running Linux).

I am the pmOS maintainer for the PinePhone. It was demoted from main to community because I was the only maintainer and one of the criteria for main is to have two or more maintainers. ( https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merg... ) Originally many pmOS core devs were maintainers, which is why it was in main, but they all lost interest and it was about to be demoted to testing / unmaintained, so I volunteered to become the maintainer to stop that from happening.

A blanket statement of a phone being "of daily driver quality or not" is impossible to make because everyone has different expectations of a "daily driver". I have been daily-driving the PinePhone since 2021 (it is my first and only smartphone) but that doesn't mean everyone else will be happy with it.

The hate comes from the company offering it under an OSS license and then taking it away. If they had started with a non-OSS license users wouldn't feel betrayed. Of course then they may not have had as many users, which is why they tried to be OSS to start with.

They used to correctly call themselves proxies back in the day. They only started calling themselves "VPNs" because "Private Network" makes for good marketing with the "hide your traffic from snoopers" angle, even though it's not the kind of private network a VPN is.

And for one-off testing there's the standard P3 Kill-a-watt.

Rust's behavior of moving without leaving a moved-out shell behind also simplifies the implementation of the type itself, because its dtor doesn't have to handle the special case of a moved-out shell, and the type doesn't even need to be able to represent a moved-out shell.

For example, a moved-out-from tree in C++ could represent this by having its inner root pointer be nullptr, and then its dtor would have to check for the root being nullptr, and all its member fns would have the danger of UB (nullptr dereference) if the caller called them on a moved-out shell. But the Rust version could use a non-nullable pointer type (Box), and its dtor and member fns would be guaranteed to act on a valid pointer.

Since RVA22 actually. B = Zba + Zbb + Zbs and RVA22 requires those individually.

Some other *renewable* energies. Nuclear isn't generally considered renewable.

It doesn't have anything to do with net neutrality. It's simply a matter of responding to abuse complaints seriously.

>The end user will find out whether their ISP is blocking them or Netflix is blocking them. Usually by asking one of them or by talking to someone who already knows the situation. They will find out Netflix is blocking them, not their ISP.

You seem to think I said users will think the block is initiated by the ISP and not the website. I said no such thing so I'm not sure where you got this idea.

>What, exactly, do you want ISPs to do

Respond to abuse reports.

>Neither one is even detectable. (Not even by the target website! They're just guessing too)

TFA has IP addresses.

>Which, on the other hand, means Netflix would ban every ISP and have zero customers left.

It's almost like I already said, twice even, that the plan won't work because the big web properties won't be in on it.

Having traits in the stdlib would be nice, but there's also the type parameter pollution that results from mocking which I think is also a turn-off, as TFA says about rsfs.

I have a Rust library to implement the UAPI config spec (a spec that describes which files and directories a service should look for config files in), and initally wanted to test it with filesystem mocks. After making some effort to implement the mock types and traits, plus wrappers around the `<F = StdFs>` types to hide the `<F>` parameter because I didn't want to expose it in the public API, I realized it was much easier to not bother and just create all the directory trees I needed for the tests.

One of them won't, but enough of them getting blocked would. People do absolutely notice ISP-level blocks when they happen. We're currently seeing it play out in the UK.

But my main point was in the second paragraph, that "enough of them would" will never happen anyway when the only ones doing the blocking are small websites.

Note that for the sake of blocking internet clients, there's no point blocking a /128. Just start at /64. Blocking a /128 is basically useless because of SLAAC.

If enough websites block the entire ISP / city in this way, *and* enough users get annoyed by being blocked and switch ISPs, then the ISPs will be motivated to stay in business and police their customers' traffic harder.

Alas, the "enough users get annoyed by being blocked and switch ISPs" step will never happen. Most users only care about the big web properties, and those have the resources to absorb such crawler traffic so they won't get in on the ISP-blocking scheme.

If OP is looking for ideas, there are two intermediate steps between the extremes of "write every line to stdout" and "build up a buffer of the whole output and then write it to stdout".

1. `stdout().lock()` and `writeln!()` to that. By default using `print*!()` will write to `stdout()` which takes a process-wide lock each time. (Funnily enough they use .lock() in the "build up a buffer of the whole output" section, just to do one .write_all() call, which is the one time they don't need to use .lock() because Stdout's impl of write_all() will only take the lock once anyway.)

2. Wrap the locked stdout in a `BufWriter` and `writeln!()` to that. It won't flush on every line, but it also won't buffer the entire output, so it's a middle point between speed and memory usage.

---

For the final proc macro approach, there is the option to unroll the loop in the generated code, and the option to generate a &'static str literal of the output.

Because the display is the bottleneck.

(From that link, about adding new subscriptions)

>The only real trick is that most YouTube channels use a vanity URL and it’s more complicated to get the channel ID in those instances.

Go to the channel's videos page ( https://youtube.com/.../videos ) -> right-click -> View page source -> search for "rssUrl" . It'll look like https://www.youtube.com/feeds/videos.xml?channel_id=UC...

Bonus: Replace the "?channel_id=UC..." with "?playlist_id=UULF..." to get a feed without shorts and livestreams.

I see the prompt-less permission config is based on the executable path. How does it get the executable path for the client? And is it robust against me spinning up a mount namespace with an arbitrary /usr/bin/grim that I control?

It's also worth noting that mfreed7 of Chromium (the person who initiated the proposal) is not the one who came up with the 357 number; that was zcorpan of Mozilla ( https://github.com/whatwg/html/issues/11523#issuecomment-320... ), so mfreed7 is talking about the list they got from zcorpan.

The ext_data_control_v1 protocol I mentioned is a protocol specifically for clipboard managers. So a client that wants to be a clipboard manager would implement that protocol. There are already implementations of it like wl-clipboard. There is no need for the compositor to broadcast regular clipboard events (wl_data_offer).

Now the compositor could certainly keep an additional list of trusted applications that are allowed to be clients of the ext_data_control_v1 protocol. Though identifying the client to enforce such a thing is a bigger problem than just maintaining a list of applications, because the protocol has no client identification. AFAIK every compositor that supports that protocol has no restrictions on clients requesting it, though something involving the security-context protocol might change this in the future.

I actually went looking at the source code to see if this would work on Wayland and it doesn't. The clipboard snooping is implemented by listening for events using gdk.Clipboard, which is not an ext_data_control_v1 implementation. So on Wayland it'll only notice clipboard events if it's in focus (or if the compositor sends clipboard events to unfocused windows, which I'm not sure any do).

https://github.com/murat-cileli/clyp/blob/2c0ce6c33813c3f35f...

Edit: Yes, tested it now and it doesn't detect clipboard events from Wayland windows when it doesn't have focus. It only detects events from Xwayland windows when unfocused, or if I copy something from a Wayland window and then focus the clyp window then it detects the thing I copied.

Only tangentially related, but RISC-V intentionally makes any instruction starting with 0x0000 an illegal instruction instead of a NOP, for exactly the reason to prevent NOP-sleds. The official NOPs are 0x0001 (compressed 16-bit instruction) and 0x00000013 (regular 32-bit instruction; instructions are LE so 0x13 is the first byte in memory), both equivalent to addi x0, x0, 0, though many other instructions can act as NOPs by virtue of writing to the zero register.

If your Firefox supports sideloading extensions then making extensions that modify request or response headers is easy.

All the API is documented in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web... . My Anubis extension modifies request headers using `browser.webRequest.onBeforeSendHeaders.addListener()` . Your case sounds like modifying response headers which is `browser.webRequest.onHeadersReceived.addListener()` . Either way the API is all documented there, as is the `manifest.json` that you'll need to write to register this JS code as a background script and whatever permissions you need.

Then zip the manifest and the script together, rename the zip file to "<id_in_manifest>.xpi", place it in the sideloaded extensions directory (depends on distro, eg /usr/lib/firefox/browser/extensions), restart firefox and it should show up. If you need to debug it, you can use the about:debugging#/runtime/this-firefox page to launch a devtools window connected to the background script.

It's also a bit telling that you read the phrase "I took it from a different FF extension that had been posted" and interpreted it as taking advice instead of reading source code.

UA fingerprinting isn't a problem for me. As I said I only modify the UA for the handful of sites that use Anubis that I visit. I trust those sites enough that them fingerprinting me is unlikely, and won't be a problem even if they did.

The string I use in my extension is "anubis is crap". I took it from a different FF extension that had been posted in a /g/ thread about Anubis, which is where I got the idea from in the first place. I don't use other people's extensions if I can help it (because of the obvious risk), but I figured I'd use the same string in my own extension so as to be combined with users of that extension for the sake of user-agent statistics.

Yes, your link from four months ago says they deployed Anubis. Now actually go to sourcehut yourself and you'll see it uses go-away, not Anubis. Or read the footnote at the bottom of your link (in fact, linked from the very sentence you quoted) that says they were looking at go-away at the time.

Sourcehut uses go-away, not Anubis.

It doesn't break the two kernel.org domains that the article is about, nor any of the others I use. At least not in a way that I noticed.