> 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.
anarazel's comment focuses entirely on performance, indicating that they have an impression that the discussion about why fork is bad is about performance. I'm not entirely sure where this impression came from, as it's not mentioned in
rom1v's quote nor a point in the linked paper, "A fork() in the road".
> 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.
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.
assign yourself permission to the device(may or may not happen by default depending on your distribution), and you can actuate it in /sys/class/leds/inputXX::scrolllock/brightness.
probably also exists other tools to do it. this is then generic linux LED framework
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.
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.
Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.
I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.
Well its also just idiotic in terms of how some huge number of people write code.
I know I'll need so-and-so import, so i write it at the top of the file before i even start, I press ctrl-s and it dissapears... I honestly laughed out loud the first time i used gopls.
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.
> 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.
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.
reply