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.
Fairly sure the user whitelist is equivalent to "Unrestricted background usage", which should be visible for user-installed apps like Briar. I have a couple of apps that need this setting enabled, and there isn't an API or manifest flag to toggle 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)?
No, they suck. No swiping, no pull-to-refresh, no multitouch zoom, the calendars dropdowns are horrible to use, the buttons look like something out of Windows 3.1
This seems to be an implication of the current market. Since most humans (and thus most consumers) use a phone or tablet as a primary computing device, it's unthinkable to make a consumer software UI that isn't mobile-first or touchscreen-focused.
"They suck" might be a bit harsh, but as someone who has used the Surface line of devices since they became good, I agree with your general sentiment. I have similar issues with COSMIC and Plasma 6 on my new laptop.
In my opinion, computer touchscreens are one of those things you don't realize how nice they are until you've already gotten used to them and are faced with the sub-par alternative. Say what you will about Windows 11, but it is extremely good for touchscreen interaction. That is not by accident. I strongly believe that any UI that takes touch seriously will significantly enhance its KB+M experience as well because it has knock-on effects on the UI. It's a bit like mobile-first. When you stop treating touchscreens as an afterthought, you are forced to become a better designer. You start thinking more clearly about information density, visual hierarchy+feedback, and most ironic of all, it makes keyboard navigation even more pleasant. I would love to see more focus on touch-friendly desktop apps, even if only for those secondary benefits.
No, it doesn't. Most workstation replacement laptops (notably including MacBooks) don't have touchscreens.
While things may be different now, Windows 8 got panned for trying to put touch elements into a desktop UI. Windows 10 and 11 would abandon that approach.
> 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.
Cache is like the old name, index is the new name, because the implementation didn't really make sense to use as a term for the users. Staging area was invented by third-parties as a term for training. Now Git uses --cached to mean only work on the context cached in the index and --index to mean also look at the --index. --stages exists as an alias for --cached for the people who want it, but it has no additional meaning and is not advertised in the documentation.
The actual documentation is actually sensible, the issue is just that most people just learn from third parties, who are lax with terms.
> At the end user level, "cache" is only used as an adjective these days; "cached", meaning "contents cached in the index, not the contents in the work tree". We could have called it "indexed", but "cached contents" was an already established phrase from very early days to mean that exact concept, and we did not need another word that meant the same thing.
> There are some commands that take --index and --cached options, and even some that can take both (but not at the same time). Many people find this confusing, but there is a pair of simple rules:
"--cached" always means "work only on contents cached in the index, ignoring the work tree";
"--index" makes a command that usually works on files in the work tree also pay attention to the index.
> Here are a handful of examples.
"git apply" usually patches the files in the work tree without touching the index.
"git apply --cached" only updates the contents in the index without modifying the file in the work tree.
"git apply --index" patches both the contents in the work tree and in the index.
"git diff HEAD" shows a patch to update the contents in the HEAD commit to contents in the work tree.
"git diff --cached HEAD" shows a patch to update the contents in the HEAD commit to contents that is cached in the index. "git diff --cached" is a short-hand for "git diff --cached HEAD" only because the HEAD commit is what you most often would want to compare the cached contents with.
There is no "git diff --index HEAD" (yet); it would imply showing a three-way diff between HEAD, the index and the work tree.
"git grep" finds matches in the work tree.
"git grep --cached" finds matches in the contents in the index.
"git rm" removes both the file in the work tree and the corresponding path in the index.
"git rm --cached" removes the path from the index, leaving the file in the work tree untracked.
> 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.
I admit that I only have rudimentary understanding, but: my understanding was that TURN uses a modified STUN format that returns the address/port on the peer facing side of the TURN server, a la address of a hotel room or PO box, of querying user. My point is that STUN/TURN(especially STUN) are not encapsulation protocols for WebRTC, but just means to determine(or get assigned, so TURN sort of is encapsulating, by being a transparent proxy) client's own public IP/port because there is no way to do so than by asking someone with a global IP.
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.
It's not that the custom firmware brings anything to the device. It just gets rid of the DRM.
Blu-ray is DRMed, so the stock firmware is capable of telling you 'no'. You don't always get direct access to the bits on the disc with the stock firmware (you can write your own discs that aren't protected, but store-bought ROM-discs are (always?) encrypted. The flashed firmware gives you direct access to the bits on the disc no matter what (region codes don't matter, the encryption doesn't matter, since your custom firmware will happily decode the disc and just hand you the files on it).
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.)
I mean, you can get the encrypted bits on the disc, except the key, so those don't really help you anything. If you ask the drive for the key, it'll tell you 'what? no, fuck off'/'that address is invalid', while one with custom firmware will just hand you the key, as it's just normal data, and then you can use that to decrypt the rest of the disc and get what you were really here for.
> 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).
> Based on what you've written, custom firmware is not actually required
This is correct for normal blu-rays, but not the UHD ones, since they add another layer of encryption. There's some nonsense going on with VUKs and MakeMKV not being able to decrypt all UHD discs, since some are encrypted with keys that aren't easily available (though you can send in a dump of the disc to the devs and they'll often change that fact for that disc).
If you know of a software library that can decrypt any random UHD disc without external keys, then please, do tell, since the MakeMKV people apparently don't know about it.
