Cloudflare has become a middleman and gatekeeper of the web, a single point of surveillance, and an enemy of the open internet. Giving them more business would make these problems worse. No thanks.
Some time back, I had a similar problem: the LineageOS Messaging app was frequently late with SMS notifications when the phone was in idle state. Adding the package to Android's deviceidle whitelist fixed it right up. (This was done with the dumpsys shell command, since the setting for com.android.messaging was not exposed in the GUI.)
I wonder if this setting could help Briar, and if so, whether an equivalent could be built in to their app packaging so users wouldn't have to fiddle with it.
What is the expected price range for registration and renewal under this TLD?
Will there be any assurance that renewal prices will remain fairly stable, rather than being significantly raised after customers grow attached to their domains (a practice that seems to be common with new gTLDs)?
> It's probably just something no one has thought of doing.
One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.
Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.
> I mean, you can get the encrypted bits on the disc, except the key, so those don't really help you anything.
They do, because a key can be obtained externally, such as with a software library made for decrypting the discs.
In any case, thanks; I think I finally understand what's going on here. Based on what you've written, custom firmware is not actually required, but it makes things more convenient (especially for folks without much technical experience).
I see. I expect DRM-encumbered discs to contain encrypted data, but I think this is the first I've heard of an optical drive withholding the encrypted bits from an application.
(And region codes aren't what I think of today as DRM. They've never been much more than silly speed bumps, so I wouldn't expect them to be at the heart of what's going on here.)
Just in case you didn't mean to be snarky, I was asking what the custom firmware brings to the device that allows using it to rip blu-ray discs that could not be ripped using the stock firmware.
> TURN is the same, but the returned IP:port is the one that had been dynamically allocated to you at time of querying, rather than the actual ones.
I don't know you mean by this, but I think you're confused. I have implemented STUN, so I know how it works. AFAIK, TURN doesn't reveal an address/port any different from that revealed by STUN, and cannot, because its discovery feature is STUN. (Also, a typical home user has only one internet-facing address, not a dynamic one plus another one.)
Rather, TURN provides a STUN address/port discovery service and a data relay service. The relay is for cases where two peers wishing to connect are both behind difficult NAT, meaning there is no quick and reliable way for them to directly connect even when they have their STUN results. So instead of connecting directly, they communicate through the relay.
> AI breaks the social contract that used to exist between an author and a reader (of prose, code, anything).
And to be clear, it is reasonable to expect an author to invest more effort than a reader, because the work in question will reach many more readers and demand time and attention from all of them.
This principle was a part of basic netiquette back in the days of Usenet. I wish I could find the document (maybe it was a FAQ?) where I first saw it stated succinctly.
I am aware of sysfs LED controls. They don't solve this problem, because access to them requires privileges (or permissions assigned by someone with privileges). It's not reasonable to expect that, just as it's not reasonable to expect a sysadmin to grant users permission to the keyboard device node before they can type anything.
Moreover, granting permissions on the sysfs nodes won't distinguish between a user who is logged in to the current virtual console and one who is not. Wayland correctly delegates keyboard ownership to compositors, but they have no way to expose the keyboard's outputs (the LEDs) because Wayland hasn't yet defined a protocol for doing so.
X11 has a protocol for this, and X servers handle it just fine. They account for different users and LED states on each virtual console, and do not require clients to have any special permissions. It's an area where Wayland fails to be a suitable replacement.
One use case is a new message indicator. Unlike icons on the desktop, keyboard lights are visible even when a full-screen application is running, or when we're to the side of or across the room from the computer, or when the display is asleep. I depend on this for my daily communications.
Another use case is for keyboard macro utilities to indicate the state of layers, modifier modes, or multi-keystroke input sequences.
Others surely exist, since hardware lights can indicate just about anything, and are especially valuable where visibility is important. Even shell scripts can use them on X11, via the xset command.