drdexebtjl

The underlying government services are hard to access _because_ middlemen stand to profit from providing assistance.

“or similar” like what?

Streaming sticks suffer from the exact same problem.

The Apple TV is the only device I know of in this space whose business model is not selling your data to the highest bidder.

Phones already have modems that do Wi-Fi, cellular and Bluetooth in a single chip.

It may at some point no longer be economical to manufacture a Wi-Fi only modem.

There’s probably an argument, I wouldn’t say it’s a good one.

It lets the author pretend to be doing software engineering, like running tests and deploying versions.

No problem, glad I could help :)

I agree this should be easier to find and set up.

I agree. In particular, I think it needs declarative configuration, and it needs to stop storing configuration in a database.

It's insane that the current setup options are:

- Click through dozens of pages importing JSONs from TRaSH Guides, then do it all over again on the other app.

- Run an app that basically does the same thing but over the REST API.

There's an official plug-in called "Subtitle Extract" that does it in advance, no need for Bazarr :)

You can use this and then block embedded subtitles on a per-library basis, which is what I vaguely described a couple of posts up.

Which streaming sticks are regular computers that run Windows?

If you mess with the firmware or try to build your own, you’ll not be able to play the higher quality formats because of DRM software.

> which means you'll need to pause for a minute before you can watch with subtitles

The entire point is that it will extract the embedded subtitles ahead of time (when the media is added to the library) so Jellyfin doesn’t have to do it when you want to watch it.

There's an official plug-in in Jellyfin called "Subtitle Extract" that does it automatically for you.

I personally use Bazarr instead, because I also want to download subtitles for different languages. In Bazarr, Embedded Subtitles is just another subtitle provider that can fetch subtitles depending on your rules.

I don't undestand how movie containers work, but I ran this on a 70 GB movie file to test:

    ffmpeg -i input.mkv -map 0:s:0 /tmp/subtitles.srt

The movie is 2 hours long, and the expected time to complete is 21 minutes. It seems like it's reading the entire file. This is on an average SATA SSD that is also being read/written to by the torrent client in the background.

I had this problem, but I fixed it by setting it up so it extracts all embedded subtitles into SRT files, and enabled a setting prevents Jellyfin from serving embedded subtitles.

From what I remember, some clients don't support streaming subtitles, so they must download them completely in advance, when the movie starts, before they start appearing. If you pick embedded subtitles with these clients, Jellyfin must extract the subtitles files immediately, and this takes a while depending on container format, file sizes and server load. External subtitles are faster.

Streaming sticks also collect your data. Roku does ACR unless you opt out.

No, you can't. They can just spoof their MAC address and be freed.

It's still a thing.

https://www.usenix.org/conference/fast24/presentation/jun

Someone decided to tell Google about this in exchange for an unknown amount of money, chosen unilaterally by Google at a later date, at which point the market value of the vulnerability is $0.

There's no way money is the motivator.

Is that not flawed on purpose?

What's the difference?

The model from TFA seems like it was being trained to browse and find information on the Web, so that constraint wouldn’t work.

The article explains why it’s not the same incident. The agents in ExploitGym had a different type of task and were not connected to the internet at all.

Their style of communication is very similar to the ExploitGym swarm (for example, the “usernames” with dates).

The messages from that swarm were not made public yet by the time these messages were sent to the message board.

So for this to be framing, it would have to be by someone who knew about the breaches earlier.

Why not? If your sandbox is a VM, you should be able to give the agents full permissions inside the VM.

This is such an amateur mistake on their sandbox that it makes me think it must be flawed on purpose.

I’m not chasing theoretical portability and checking off a box saying my code is 100% pure ISO C. If that’s important to you, don’t do this (and also don’t use pretty much any allocator!)

Every sufficiently useful C codebase assumes specific implementations.

I don’t see the problem if you stick with .com or the ccTLD for the country you live in.

To me, the risk these registries screwing me over is smaller than Big Email deciding I broke their ToS and shutting down my account.

I wouldn’t use these novel TLDs either.

Sovereignty? If you live in the UK, choosing a registry in the UK is a pretty good idea even if they only offered 3rd levels. You’ll have someone to contact and possibly sue locally. Your domain will be subject to UK law and standards, not those of a foreign registry.

If payload was ever dereferenced as a char array as well, I would buy the strict aliasing argument. But it’s not, it exists as a char pointer solely for pointer arithmetic.

AFAIK The purpose of strict aliasing rules is to let the compiler assume that dereferencing pointers of different types never refer to the same memory.

If ISO C treats this as UB, shouldn’t ISO C be fixed?

In practice you wouldn’t have the payload in the struct at all, just a fixed offset aligned with the maximum alignment, but this is more illustrative of what’s happening for an example.

IIRC GCC and Clang lets character types alias to any type. Otherwise glibc’s malloc also doesn’t abide to strict aliasing.

> It is awkward in C, where the implementation has to be macro-generated.

You can avoid having the implementation be macro-generated by "hiding" the list pointers before a char payload[0]. See https://pastebin.com/DE69mbJD for an example.

The same technique is used by glibc's malloc to store metadata about the allocation right next to your data, and then recover it when you call realloc/free, without needing a separate metadata allocation.

The caveat is that the type of the pointer does not indicate provenance. For example, nothing stops you from calling list_next on an arbitrary pointer to data that is not on a list, and that would be UB. The same happens with realloc and free, where it's UB if you pass them a pointer that was not returned by the heap allocator.