foresto

Or maybe expose the LPC bus to a VM, and wire the relevant lines to an ISA bridge?

https://en.wikipedia.org/wiki/Low_Pin_Count#ISA-compatible_o...

https://www.youtube.com/watch?v=putHMSzu5og&t=208s

https://github.com/rasteri/dISAppointment

I wonder about the dependency graphs of all these replacement utilities.

The vast majority of Rust projects I've seen pull in hundreds, sometimes even thousands, of external projects. If Ubuntu's rusty tools do the same, any memory safety gained would come with a greatly increased supply chain risk.

Doesn't attack surface matter?

Avoid the Hakko FX-888D soldering station. This device has one of the most bizarrely obtuse interfaces I have encountered in ages, seemingly designed to make basic adjustments as difficult as possible, and to encourage accidental decalibration of its temperature settings with no indication to the user that it has happened. I wish I had returned mine while I had the chance.

What do you mean by "a real recaptcha"? I just went to an archive.is page, and it's trying to load a script from www.google.com. Doesn't Google still own reCAPTCHA?

Until adoption expands beyond Facebook to services that we want.

Or to things that we need, like medical care, government interactions, and financial services.

People shouldn't have to choose between safety features like those in Graphene OS and participation in society.

Let's be fair: At least some of the features you quoted do work in KDE connect in my experience, so I had the same question as GP. Even after reading the article.

This is not the Motorola (USA) that many of us knew for ages. That company doesn't exist any more.

The company working with GrapheneOS appears to be Motorola Mobility, owned by Lenovo (China).

Does login.gov require photos, videos, fingerprints, smartphone apps, or similar nonsense as ID.me does?

Or does it offer less invasive ways to confirm identity, like mailing a code sent to one's long-established postal address, or an in-person visit to a local social services office?

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

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/