foresto

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.)

https://source.android.com/docs/core/power/app_mgmt#testing-...

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.

Direct P2P connections using Iroh gossip protocol over QUIC

How does it handle NAT traversal?

Those are touchscreen actions, uncommon in desktop apps. Did you forget that this thread is about avoiding Electron bloat?

(Also, it has a theme engine. The buttons don't look like something out of Windows 3.1 unless you use a Windows 3.1 theme.)

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)?

Qt Widgets are good.

In which jurisdiction?

If mpv on Linux and MPC-HC on Windows, what is recommended on macOS?

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.)

That much is obvious.

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.

What can the custom firmware do that the stock firmware cannot?

The problem with fork isn't really that it's slow.

Did someone suggest that it was?

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.

My Wayland pet peeve:

It still lacks keyboard LED control, so unprivileged X11 programs that use the Scroll Lock light as an indicator cannot be ported to Wayland.

This Plasma change is going to be painful for me. I wonder if there's an up-to-date list of Wayland shortcomings.

I'm not sure what you're trying to recall, but regarding Qt licensing, perhaps you'll find this interesting:

https://kde.org/community/whatiskde/kdefreeqtfoundation/

It doesnt let you have unused variables

Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary.

It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally adding a new feature. It's an important part of my exploration process.

When I hit Compile at that point, I expect the compiler to build the work-in-progress exactly as it is in that moment. Executing the output allows me to spot check the snapshot's behavior against my expectations and mental model. The compile step also assures me that no syntax errors have crept in while I was focused on the logic flow or general shape of the code.

When a compiler refuses to do its job, and instead barfs up spurious errors complaining about unused variables, it brings my workflow to a screeching halt. In order to make progress, I am forced to abruptly leave my current context to visit all the different places where those variables are introduced, edit them, try again, discover that those forced edits have left more variables unused, and repeat the process until the combative compiler shuts up and does what I told it to do in the first place. By the time I'm allowed to return to what I was doing, my train of thought has been derailed, the bits of logic that I had been juggling have fallen to the ground, and my focus destroyed. And then, once I have recovered my original thoughts and seen the output of my snapshot build, I have to go back and revert all those forced edits before I can resume my work.

What an aggravating, disruptive, and completely unnecessary waste of my time and attention.

I hope Andrew has the good sense to let errors of this kind be silenced or demoted to warnings, perhaps with a compiler flag or debug build mode.

The first time I saw something like this was in a music-focused virtual world from the 2000s. Strangers would strike up conversations with each other, dance (in some cases to well-known artists), wander around to see what others were doing, and generally just hang out.

I think it was called vSide.

https://en.wikipedia.org/wiki/VSide

This title evokes memories of The Twilight Zone's To Serve Man episode.

If the email matches their GitHub account, GitHub links the commit to their profile and grants them contributor status.

When the article mentioned email matching, I was concerned that it would break down when a contributor's email address changes. (I have contributed to more than a few projects over the years, using email addresses that no longer exist.)

However, it looks like they're not using the email address recorded in the author's original git commit, but instead a GitHub-generated address whose unique parts are the GitHub user ID and username. That should survive authors changing their email addresses. It would still break down if a contributor loses access to their account and has to create a new one, but that's probably less common.

This could be read as reductive, presumptuous, ignorant, and insulting.

At the same time, it's often technically true, but for a good reason that you neglected to mention:

Those old tools tend to be very capable email clients, not web apps with their awkward attempts to simplify complex conversation structure. A good email client can handle large, high-traffic, frequently branching, long-lived threads with ease. All the web forums I've ever used fail miserably here.

The people who are tasked with participating in large scale discussion groups (like the LKML) know this through experience. They prefer email because it works better. It makes their lives easier. It helps them to be more efficient, which is absolutely necessary given the sheer volume of messaging that they handle.

Yes, a specialized tool is required to get these benefits, just as a specialized tool is required to make web server output easily readable. Thankfully, these tools have existed for decades.

In case anyone else likes to know the panel manufacturer before buying a display, it looks like this one is made by Samsung.

https://www.displayspecifications.com/en/model/f86e3770

https://www.displayspecifications.com/en/model/49bc3e67

I helped them make the wrong choice, Mercurial.

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

Of course, it would also create a demand for open-source game server libraries, which would surely appear after a while and make the whole process much easier.

So while I believe you about all those difficulties existing today, it's plausible that they would mostly fade away over time. I think temporary growing pains would be an acceptable price for the significant long-term public benefit.

Thanks. Outside of LLM circles, DS4 is usually a video game controller.

Government leaders will never give up their pipeline of knowing everything about everyone.

Then let us hire different leaders into government. Public servants, not overlords.

for (third-party) sale

Many of us find it unethical to give money to scalpers.

a handful of .net domains that are under $100

And this is why.