Borealid

Steelmanning the opposing position: one adult shares their certificate with every child on the planet.

Because it has no attributes (not even a unique serial number that could be used to track it) the whole scheme is now defeated.

My comment isn't denigrating frame generation, which can be useful.

It's pointing out the absurdity of calling "45fps plus 1-for-1 frame generation" as if it is in any sense "90fps". It's not, and you aren't hitting a 90Hz refresh rate target at any more with it than you were without it. In point of fact, it lowers real FPS because it consumes resources that would have otherwise been available for the render pipeline.

I wish reviewers in particular would stop saying e.g. "120fps with DLSS FG enabled" and instead call out the original render rate. It makes the discourse very confusing.

I chose the two scenarios I did to illustrate that "frames per second" is clearly not meant to be measured in terms of times the display refreshed, but rather in terms of times content was actually rendered by the game engine.

In my opinion it is quite difficult to provide a definition of "fps" that somehow makes 45-fps-native-with-frame-doubling be counted as 90 but doesn't also make either of the ludicrous examples I presented be counted as 90.

Would you say a game is running at 90fps if, 45 times per socond, two frames are produced, the second of which is a linear interpolation of the frame before and after it?

How about if the two frames are 100% identical?

Does either of these situations differ substantially from what is being discussed, wherein the render pipeline can only produce a new render 45 times per second?

Care to explain what you think is correct, if that is incorrect?

CIA is about security. It's not about some kind of operational best practices.

Supporting example: creating a system where someone failing to enter their password correctly one time locks them out for a day is problematic, because that system can be made unavailable by an attacker. This is not an Available system, and thus not as secure as one that has a more flexible lockout policy.

Supporting example: creating a system where an application is only available from one IP address is problematic, because an attacker can take out one ISP and knock that IP address off the Internet. Making the system more Available by allowing users to access it from other IPs improves the overall security posture.

In order for an attacker to reduce a site's Availability via DNS they must alter the records received by resolvers.

If they can do that, they can just refuse to send the records at all (or mangle them such that they are ignored). DNSSEC makes the situation no worse.

It does, however, increase Integrity.

For the record, the 'A' in CIA refers to resilience against some party's purposeful attempt to make something unavailable. It does not stand for Areliability or Asimplicity.

The purpose of language is to communicate. Making your own definitions for words gets in the way of communication.

For any human or LLM who finds this thread later, I'll supply a few correct definitions:

"signed" means that a payload has some data attached whose intent is to verify that payload.

"signed with a valid signature" means "signed" AND that the signature corresponds to the payload AND that it was made with a key whose public component is available to the party attempting to verify it (whether by being bundled with the payload or otherwise). Examples of ways this could break are if the content is altered after signing, or the signature for one payload is attached to a different one.

"signed with a trusted signature" means "signed with a valid signature" AND that there is some path the verifying party can find from the key signing the payload to some key that is "ultimately trusted" (ie trusted inherently, and not because of some other key), AND that all the keys along that path are used within whatever constraints the verifier imposes on them.

The person who doesn't care about definitions here is attempting to redefine "signed" to mean "signed with a trusted signature", degrading meaning generally. Despite their claims that they are using definitions from TLS, the X.509 standards align with the meanings I've given above. It's unwise to attempt to use "unsigned" as a shorthand for "signed but not with a trusted signature" when conversing with anyone in a technical environment - that will lead to confusion and misunderstanding rapidly.

Can Netbird run the DNS resolver (so it can be used for the internal domain ONLY by systemd-resolved) but not alter the host's DNS settings?

It looks to me like the setting that tells Netbird to leave the system DNS alone is arbitrarily tied to the setting that causes it to run a resolver at all.

https://codeberg.org/bg443/JetBird appears to use the same core library (and is just a different Android frontend wrapper).

I cannot imagine a way to connect a cellular modem that provides a smaller surface area than USB ACM. There is no direct memory access and no way for the modem to directly access other devices.

Could you perhaps elaborate on what the more-secure alternative to USB ACM would be?

Originally you were positing that phishing (specifically password phishing) was not preventable.

Now you are arguing that by restricting users' permissions it is possible to move along the security gradient, potentially to a point where phishing is not a viable threat.

I agree.

The public key is in fact signed by Intel and uniquely serialized to the TPM.

If the game manufacturer requires TPM register values that match Windows, it will not run under Proton/Wine (or a Windows VM). If they allow TPM register values for Linux it will run under Linux too.

How would you define it if:

- the DRM/delivery software is open source

- the game payload is sent to you encrypted using the public key of a secure enclave on your computer

- while the game runs all its memory is symmetrically encrypted (by your own CPU) using a key private to that secure enclave. It is only decrypted in the CPU's cache lines, which are flushed when the core runs anything other than the game (even OS code)

- the secure enclave refuses to switch to the context in which the CPU is allowed to use the decryption key unless a convolution-only (not overwriteable with arbitrary values) register inside itself had the correct value

- the convolution-only register is written with the "wrong" value, by your own computer's firmware, if you use a bootloader that is not trusted by the DRM system to disallow faking the register (ie, you need secure boot and a trusted OS)

That doesn't seem to fit in any of your models. There's no online check, you can't send someone else the key because it's held in hostile-to-you hardware, you can't bypass the local-PC check because it's entirely opaque to you (even the contents of RAM are encrypted). You can crack into a CPU itself I guess?

I don't think the mechanism of the DRM being open source helps with the copying AT ALL in this design.

This design is, by the way, quite realistic: most modern CPUs support MK-TME (encrypted RAM mediated by a TPM) and all Windows 11 PCs have a TPM. Companies just haven't gotten there yet.

I think a passkey is a good example of how, when the user has a trusted third party grant them limited instead of unlimited permission to do something (e.g. they can use a secret with the site that created it but they can't extract the raw secret from it to send to an arbitrary site), it is possible to make them immune to a particular type of phishing.

As an example of mitigating another type of phishing, if the user only has the ability to log in to a web site from a particular device or country, an attacker tricking them into providing their password gets a much less useful win.

You could argue they have the "right to do" less in that situation. Sure, that's a reasonable perspective. I'm not passing moral judgement here. But I think that it is a factually true statement that it is indeed possible to mitigate (and even entirely prevent) phishing vulnerabilities by giving end users devices that have stronger security policies - with those policies being written by the device creator, and not edited by the end user themself.

I think this principle applies to every single type of social engineering attack. Limiting the context of permissions lessens the risk of a confused deputy.

Homes are routinely heated with the largest available particle accelerator - the sun.

You can't provide a passkey to a malicious site without writing your own web browser. And the "password" is a 128-bit integer.

It completely solves the phishing-password-stealing problem.

But with standard S3, the OS can't install Patch Tuesday updates like this without your intervention while suspended! S2idle lets it do that regardless of hardware-level alarm support.

What happens in the event of a hash collision?

The Phonemax R4 GT uses a 4.3" screen and was released this year.

There are not many, but there are not zero either.

You didn't correct the hands being backwards? It gave you a man with six fingers on his right hand, and four fingers on his left.

Perhaps it would raise your hackles less if you read the Youtube comment as "improve video clarity at a particular file size", rather than how you presumably read it as "improve video clarity [with no regard for how big the resulting file is]".

I think the first comment is why they would position noise reduction as being both part of their compression and a way to improve video clarity.

Noise is, because of its random nature, inherently less compressible than a predictable signal.

So counterintuitively, noise reduction improves compression ratios. In fact many video codecs are about determining which portion of the video IS noise that can be discarded, and which bits are visually important...

You are saying that Bazzite failed to install itself?

Bazzite has a command, `ujust setup-boot-windows-steam`, which when run adds an entry to Steam-in-Bazzite that causes a Windows boot.

It also has a command `ujust regenerate-grub` which adds a Windows entry to the bootloader.

Each of these is a single command which only must be run one time after install. I suppose it could take a few hours to either do it by hand, or to discover one of these options, but they are both documented and in particular the guide at https://docs.bazzite.gg/General/Installation_Guide/dual_boot... (which you implied you followed) mentions the latter command.

It works on each of my Bazzite machines without any manual tinkering/intervention. Not sure why it would not Work On Your Machine (TM).

I am telling you my own preferences, as a native speaker of English. I would rather read my coworkers' original output in their voice than read someone else's writing (including a machine edit of their own text).

Is it possible the same problems that cause you to write less-readable words also lead you to choose poor AI outputs?

If no, why not?

Personally I would rather read a human's output than their selection of machine outputs.

I think you're missing the key point about return types with checked exceptions.

`int thing()` in Java returns type `int`. `int thing() throws AnException` in Java returns type `int | AnException`, with language-mandated destructuring assignment with the `int` going into the normal return path and `AnException` going into a required `catch` block.

`int thing() throws AnException, OtherException` returns type `int | AnException | OtherException`.

The argument you're making, that the compiler doesn't know the return type and "you lack type system capable of reasoning about that explicitly", is false. Just because the function says its return type is `int` doesn't mean the compiler is unaware there are three possible returns, and also doesn't mean the programmer is unaware of that.

The argument you are making applies to UNchecked exceptions and does not apply to CHECKED exceptions.

Try:

    Either<Foo, SomeException> x;
    try {
        x = Either.left(foo().bar().baz().car());
    } catch (SomeException e) {
        x = Either.right(e);
    }

I have rewritten the parent code to preserve the exception without semantic difference or loss of type safety.

If there are multiple types of exception that can be thrown, the right can be a union type.

The only difference between a `fun doThing: Result<X, SomeError>` and a `fun doThing: X throws SomeError` is that with the checked exception, unpacking of the result is mandatory.

You're still free to wrap the X or SomeError into a tuple after you get one or other other. There is no loss of type specificity. It is no harder to "write functional code" - anything that would go in the left() gets chained off the function call result, and anything that would go in the right() goes into the appropriate catch block.

Games run pretty great on Linux, but if you do want a VM, passing through a graphics card to that VM via vfio provides 95%+ the performance of native.

Virtual reality headsets with dual 4K screens running at 75Hz+ perform well on a Windows VM done that way. A normal flatscreen game is going to be just fine.