• 0 posts
  • 270 comments
Joined 3 years ago
Cake day: June 13th, 2023
  • A docker container’s IP usage heavily (entirely) depends on how the container’s networking is defined by the host machine. And in an overwhelming amount of cases, that host networking will be a “here’s a device-local subnet your containers can join to”, so no, a Docker container won’t by default “get it’s own IP address” (colloquially, “its own IP address” would refer to a device getting a LAN-local address assigned to it from the local gateway/DHCP server), at least not one other devices on the network can access.

    Also claiming that “nothing else will use port 80” is a gross over-simplification.

    The move to port 80/443 on HAOS makes sense as it simplifies setup for total beginners.

  • “The best” depends on what you really need.

    Authentik and Authelia are two of the top most quoted solutions, but they aim to be an “everything in one” package, with tons of features a simple homelab will rarely need. They’re aimed more at enterprise-like setups.

    On the other end of the spectrum you have e.g. Pocket-ID, which only does OIDC by itself (you can hook up an LDAP server as user database though); but that tradeoff means it uses little to no CPU time, and, in my experience, around 130MB RAM. Given RAM is getting more expensive than gold, one needs to consider memory footprint, especially for older homelab setups. We can’t all be running 256GB nodes after all.

    So instead of hunting the mythical “best” solution, decide what features you really need, grab a list of providers that cover those features, and compare them to see what fits your needs best.

  • Funny thing is that we have multiple examples of these AI fine-tunes backfiring spectacularly.

    For example all the Grok fails on Xitter, and Elon promising to fix those results constantly, without any of those sticking.

    I think the bigger problem is that there’s a segment of the population that’s gotten so dependent on “AI” (LLM chatbots), they literally can’t learn without it. Even the most mundane things they could’ve easily looked up via a search engine, end up as a question to ChatGPT. And no matter how many times you show them that the chatbot gave insanely wrong results, they’re still going to use it.

  • It’s incredibly vague still, that’s the problem.

    Like, I see, if I wanted to roll my own shitcoin, I can’t publish the source code of it on Codeberg.

    But, say, a Blockchain lookup app - technically it’s a cryptocurrency related project, but at the end of the day it’s just an app that connects to a public API and lists data from it. Is it also banned?

    Or, I make an open source smart clock, from an LED matrix and an ESP32. This smart clock can link to YouTube/Twitch/etc. for viewer count, to GitHub for project stars/forks, to currency exchanges, and one includes a crypto exchange rate tracker for displaying current mainstream coin valuations (say, the top 5 most used coins). Is this project, since it’s crypto related, banned?

    Or let’s say I come up with something blockchain adjacent, that could be utilised for cryptocurrency use… and what if I just publish a new cryptographic approach that then gets used by a new cryptocoin that suddenly becomes famous?

    Or if my project uses a cryptographic system that comes from a dependency that was broken out of a cryptocurrency project?

    Where do we draw the line of “related”? What level of relationship is allowed with the world of cryptocurrency? What degree of separation is deemed appropriate?

  • The recommendations so far are quite solid.

    I’d also add that crowdsec with the right collections as a primary filter within your reverse proxy setup can be extremely useful, potentially even better than fail2ban, as CS delivers a literal “scan every packet and put them against these rules” approach - where the rules are crowd sourced, thus are more up to date than any manual blocklists, filter list etc. can be, and can spot even 0day intrusion approaches.

  • I’d argue that AI does change things:

    • on one hand it increases the percentage of invalid/unusable images. A mis-labeled image is still potentially useful, an image of a toucan in the Arctic isn’t. This means that even large datasets become largely unusable because of the volume of fake images.
    • on the other hand any AI picture that slips through, taints the dataset and results in expensive manual cleanup to ensure data is reliable.
  • I’m actually working on an all in one solution that sort of fills the roles of Readarr AND Calibre - without all the baggage of the latter.

    Oh, and of course a KOReader library plugin that foregoes OPDS and works like the Kindle interface (“available books” synced from this backend, one tap downloads them, plus potentially adding series handling too in the future).

    But right now it’s mostly manual downloads + CWA ingest + OPDS via KOReader.

  • They also have all the data in a set of torrent files.

    I’ve actually been working on an AA client + Readarr (yes yes I know the main project is dead, I meant for generally book-related Arr stack projects) provider.

    The idea is pretty straightforward:

    • the client connects to the current AA instance and grabs the torrents
    • each torrent is added to a built-in client, with all files set to “don’t download” (so at the moment it does nothing beyond peer discovery)
    • each torrent is now versioned and provides a metadata batch of all files and paths included
    • metadata is matched to paths during lookup
    • provider interface allows upstream software (e.g. Readarr, Chaptarr, etc.) to search for a specific release with some extra parameters (language, format, date added, etc.), uses AA approach of hash to path matching
    • path is matched to torrent, within that torrent, that path is set to be downloaded
    • upon download the file path is softlinked to destination provided for download
    • upstream picks up new file and parses it (then it gets passed to CWA, AudioBookShelf, Kavita or whatever other frontend you use)
    • the client also automatically selects 500MB worth of files with low availability. This 500MB is separate from what the user has actually downloaded, and is used to contribute back to the P2P net
  • Those guns STILL REQUIRE KEY COMPONENTS THAT CANT BE 3D PRINTED. Just how many times and how many ways do I have to explain this until it gets through?

    You can 3D print a shadow gun, sure, even on a $100 cheapo FDM printer. Thing is, it won’t fucking work because there’s neither barrel nor firing pin. Two of the, oh, most crucial elements to make a gun into an actual gun. Up until you add these two bits, that gun will do more damage if you chuck it at your target than if you fired it.

    TECHNICALLY, you could get away with a firing pin setup made from some wiring and an actual nail, but it would be highly unreliable - misfire, not fire at all, and so on. And even if it did fire, without a barrel, you’d have a 30-40% chance of not hitting your target… at which point you’re more likely to kill your target by aiming some higher power pyrotechnics at them. Which are easier and cheaper to acquire.