Preferences

Retr0id
Joined 11,194 karma
https://www.da.vidbuchanan.co.uk/blog/

https://github.com/DavidBuchanan314

at://retr0.id

@retr0id@retr0.id

<script>document.location="https://www.youtube.com/watch?v=dQw4w9WgXcQ";</script>


  1. Then how do people with free accounts listen to music lol

    (It is plausible they added some new DRM but it's not going to be anything too crazy)

  2. There are two ways to answer this, one for what I'd intrinsically enjoy most, and one for what could be an equally lucrative career.

    For the former, a repair/handyman. Hanging shelves, assembling ikea furniture, etc.

    The latter is harder to answer, but probably something within the legal profession.

  3. You are correct
  4. What benefit do you get from the splat-ification? Surely any relevant details are visible in the original jpegs?
  5. Spotify has DRM, and you can find open-source reimplementations of it on github.

    Their native clients use a weak hand-rolled DRM scheme (which is where the ogg vorbis files come from), whereas the web player uses Widevine with AAC.

  6. Notably 160kbit is the free-tier bitrate, so they presumably used unpaid accounts.
  7. I had claude implement the random-huffman-trees strategy and it works alright (~20MB/s decompression speed), but a minimal huffman tree that only encodes the end symbol works out even slower (~10MB/s), presumably because each tree is more compact.

    The minimal version boils down to:

        bytes.fromhex("04c001090000008020ffaf96") * 1000000 + b"\x03\x00"
  8. There are also deflate-specific tricks you can use - just spam empty non-final blocks ad infinitum.

        import zlib
        zlib.decompress(b"\x00\x00\x00\xff\xff" * 1000 + b"\x03\x00", wbits=-15)
    
    If you want to spin more CPU, you'd probably want to define random huffman trees and then never use them.
  9. I think these mitigations are misguided and I've had false-positives at least once. Rather than caring about structural details (overlapping files etc.), decompressors should just limit the overall decompression ratio by default (bytes in vs bytes out). It shouldn't matter how the ratio is achieved.
  10. Doesn't seem to be live, otherwise there'd be one that says "Hacker News front page now, but the titles are slop"
  11. You might get close in peak bandwidth, but not in random access and latency.
  12. Working fine in Firefox
  13. I wonder if there's any possibility that an RDMA expansion device could exist in the future - i.e. a box full of RAM on the other end of a thunderbolt cable. Although I guess such a device would cost almost as much as a mac mini in any case...
  14. Yes, you'd take different actions to avoid each.
  15. I'm not thinking about deliberately embedded vulnerabilities, just accidental/emergent ones. The modern equivalent of devs copy-pasting stackoverflow answers that happen to contain SQL injection vulns.
  16. You can more easily check for known-vulnerable dependencies
  17. It's going to be fun if someone finds a security vulnerability in a commonly-emitted-by-LLMs code pattern. That'll be a lot harder to remediate than "Update dependency xyz"
  18. These kind of LLM bots can be fun to play with in a "try to make it say/do something silly" way, but beyond that I don't really get the point. The writing style is grating and I don't think I've ever seen one say anything genuinely useful.
  19. Until your comment I didn't realise I'd also read it wrong (despite getting the gist of it). Attempted rephrase of the original sentence:

    Imagine history documentaries where they take an old photo, free objects from the background, and then move them round to give the illusion of parallax.

This user hasn’t submitted anything.