Skip Navigation
InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)XA
Posts 4
Comments 1.4K
I am a software developer at PornHub
  • There's a lesson here for lurkers looking at this conversation :-) Block people all you want. You don't need a good reason. There's no Socratic Method Fairy who's gonna get mad at you for refusing to engage with bad faith arguments, lying, or abuse. Just click on the username, the block button is near the top and pretty big.

    About to block a few accounts here myself.

  • Latest Verge article about their review of Asus ROG Ally X (and this is why gamers are preferring Steam Deck)
  • I am slightly ashamed to admit the reason I'm not going to consider pop os is the stupid way they write it: Pop!_OS.

    I'm already running 11 Linux VMs (and 3 bare metal Linux OS's) in my homelab so I think I've got plenty of Linux here anyway.

  • Single point of failrule
  • I understand what you're saying about failing early. That's a great strategy but it's meant to apply to production software. As in, your product shouldn't even start up if critical parts are missing or misconfigured. The software should be capable of testing its configuration and failing when anything is wrong, before it breaks anything else. During the development process, failing early also speeds up iteration cycles, but again, that's only when it's built into the sw runtime that it carries with it.

    "Fail early" can also mean your product stops working and shuts down as soon as its environment changes in a disruptive way; for example, if you're using a database connection, and the database goes down, and you can't recover or reconnect, you shut down. Or you go into read-only mode until your retries finally succeed. That's a form of "fail early" where "early" means "as soon as possible after a problem arises".

    You don't want your development processes to move fast and break things. If your dev and staging environments are constantly broken because you moved fast and broke things, you will ship broken software. The more bugs there are in there due to your development practices, the more bugs you'll ship, in a linear relationship.

    QA and controlled development iterations with good quality practices and good understanding by all team members is how you prevent these problems. You avoid shipping bugs by detecting failures early, not by making mistakes early.

  • Mushroom Guides
  • If it bruises blue, cut off a very thin slice from the center of the stalk and put it on agar until it creates mycellium. There's some other stuff you need after that which I'll be happy to help you with.

  • Personal music servarr with a mobile app?

    I've been on Tidal for years, but it's frustrating to use for lots of reasons (they only pay their artists slightly better than Spotify, streaming services are flaky, works poorly with my DLNA home speakers). I'm looking for something I can selfhost with the following features, and I would appreciate any suggestions in this direction:

    • integrates with downloading services (nzbget and qbittorrent; or better yet prowlarr)
    • has a suggestions/radio/mix feature, or integrates well with something that does. I currently use jellyseerr for other kinds of media, so something in that vein.
    • has a mobile app which lets me download all the tracks I want, or integrates with one that does. Big bonus points if the mobile app can play to DLNA speakers.

    A bit about my lab:

    • Proxmox-based, lots of VMs and containers on 2 different cluster nodes. Lots of underprovisioned RAM in the cluster. Nodes run Fedora and I'm partial to quadlets, but I can convert anything to a quadlet if I need to.
    • Airvpn port tunneling is available to me.

    TIA!

    29

    What do you with physical light switches connected to automations?

    I'm setting up with HA and zigbee smart bulbs. I've got a few automations already set up, such as turning on a bunch of lights in the morning and turning most of them off again at night.

    All these lights still have physical switches. I don't want to take those switches out for lots of reasons, and putting smart switches there seems like overkill when the bulbs are already smart. What are people doing with their physical light switches to ensure that they don't get flipped?

    Ideas I've had:

    • some kind of physical plastic covering that fits snugly around it. I'd probably do this if I had a 3d printer, but I don't. Maybe someone sells a thing like this? More just a reminder not to touch them.
    • Carefully paint the switches a different color (perhaps the HA color scheme?). Again, basically just a reminder. This especially makes sense with a few multi-switch plates where some of the connected lights are automated and some are intentionally left manual.
    • Entirely replace the plate with a smart switch? Besides incurring a nontrivial cost and being a bunch of work to install, this won't even help me with the aforementioned multiswitch plates. I don't want all my lights automated.

    Other ideas?

    32
    Connect A Song @lemmy.world xantoxis @lemmy.world

    Far Away - Red Dead Redemption Soundtrack

    This song plays in RDR (the first one) when you enter the nation of Mexico.

    0
    Connect A Song @lemmy.world xantoxis @lemmy.world

    The Doors - Break on Through to the Other Side

    Seems self-explanatory

    0