Aussie living in the San Francisco Bay Area.
Coding since 1998.
.NET Foundation member. C# fan
https://d.sb/
Mastodon: @dan@d.sb

  • 0 Posts
  • 429 Comments
Joined 3 years ago
cake
Cake day: June 14th, 2023

help-circle
  • To get started, I’d say to get a cheap block account from the Reddit Usenet deals wiki: https://www.reddit.com/r/usenet/wiki/providerdeals/. A block account gives you a fixed amount of download (1TB, 2TB, whatever) that lasts indefinitely. If you use it just for music or books (for example), one block could last you a very long time. If you find yourself needing more data, you can get a monthly subscription with unlimited data.

    You also need an indexer, which is how you search for content. DrunkenSlug, NZBGeek, and NZBPlanet are popular. These cost money, but sometimes they have a lifetime plan where you just pay once. Sometimes they have open registration, but other times you need to get an invite from an existing user. There’s free indexers like NZBKing, but they’re often full of junk, and lack encrypted content.

    SABnzbd is the most popular downloader software. It’s free and open-source.

    • Add account to SAB.
    • Search for what you want on the indexer.
    • Download the nzb file (points to where the files are located on Usenet) and add it to SAB to download the contents.

    I think that’s it for the basics. There’s more to it - different backbones have different data so one provider might have data that a different provider is missing , you can fully automate downloads with Lidarr/Radarr/Sonarr/Readarr, you can aggregate results from multiple indexers using NZBHydra/Prowlarr - but you can figure that out as you go :)
















  • Yes, unstructured. Every script is its own special snowflake that does things a bit differently.

    There’s no guarantee of the verbs that the script implements. start, stop and restart are common, but the implementation is up to each individual script. I’m most familiar with Debian where some service (but not all) implemented it with start-stop-daemon, but other distros and OSes handled it differently.

    Basic, commonly needed functionality, like restarting a crashed service after waiting for some delay, need to be implemented per app.

    When sysvinit was widespread, there was a reason a lot of people used systems line supervisord to deploy services, rather than dealing with sysvinit scripts. It was a pain.

    Systemd units were a logical progression from supervisord services.