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/)SH
Posts
1
Comments
290
Joined
2 yr. ago

  • Or many service providers competing on price, quality of service and features, not competing on exclusivity like they do now.

    Like grocery stores. Imagine if only one chain has the exclusive rights to sell potatoes and another one has rights to pasta. They can ask whatever price they want, because what you gonna do? Go to another store to get your 'taters cheaper? Hah, you'll cry and you'll pay what we ask! (BTW, growing your own potatos and sharing them with your neighbor infringes on our rights and is illegal. We'll sue you to oblivion if we catch you doing it.)

  • Prime example that for a publicly traded company the people buying the products are not customers for whom to create value, but a resource to extract value from.

    Shareholders are the real customers for whom they create value.

  • It all comes down to the size of the mirror/lense—the bigger, the better. Up to a point. The biggest problem is air currents and different air densities refracting light and distorting the image. That's what these laser beams are for on photos taken of astronomical observatories—they give reference light spot that can be used to calibrate adaptive optics to current atmospheric conditions reducing distortion.

  • What we know about drones is that they have cameras that can discern individuals from 10 km altitude.

    What we suspect is that US has Hubble-sized spy satellites that can do almost the same. There were a lot of classified military STS missions.

    What is theoretically possible is that US drones and spy sats can function as very large arrays (we do this with astronomical telescopes already) to dramatically increase spatial resolution.

  • On my server:
    OpenMediaVault (NAS OS based on Debian)
    Syncthing
    Home Assistant
    Zigbee2MQTT
    Docker
    Portainer
    Radicale
    Navidrome

    On my phone:
    Syncthing
    Tailscale
    Feeder
    DAVx⁵
    OSS Document Scanner
    RPNcalc
    DSub
    EDSY

    On my PC:
    Odyssey Material Helper
    EDDiscovery
    EDSY
    ObservatoryCore
    Paint.net and GIMP
    OpenRGB
    Tailscale

  • Another audio professional here. For line level analog audio (it's different for guitar pickups and turntable cartridges) it doesn't matter much at all unless we're talking long cable runs (several tens of meters and more) or some badly designed equipment that can't handle high capacitance cables (eg I've had crappy amps going into oscillations with certain speaker cables). What matters is shielding (in noisy EM environments) and reliable connectors.

    Digital audio is a different kettle of fish, but it's amazing what you can get away with when runs are a few meters or less. Consumer-grade equipment almost never has 75 ohm connectors for coax S/PDIF and no consumer S/PDIF cable is really 75 ohms. RCA connectors cannot be 75 ohms due to their geometry and BNC is a rare beast (I really had to go out of my way to set up proper 75 ohm cabling for digital audio in my home, and still am not sure the BNC connectors I use are actually 75 ohms).

    I should also mention to all non-audio pros that you can't measure a cable's or a connector's characteristic impedance with a simple multimeter. 50, 75 and 110 ohm cables/connectors will all show milliohms on a multimeter and are all fine for audio frequencies. Characteristic impedance only plays role at high frequencies—MHz, not kHz range and when we need to impedance match the whole transmission line to avoid signal reflections.

    I would be more worried about channel crosstalk when using a multi-core cable where conductors are not individually shielded as is the case with USB cables, but even 30 dB separation is probably fine for casual music listening.

  • Check out Behind the Mask: the Rise of Leslie Vernon. It's a satirical horror comedy that takes the common horror tropes, deconstructs them and turns them inside out, upside down in a hysterical way.

  • Wouldn't any off the shelf temperature+humidity sensor work? I use Sonoff and Aqara ones with Sonoff Zigbee coordinator and Zigbee2MQTT, both are somewhere around 15€ a pop, integrate painlessly and do the job. Aqara is a bit smaller and has air pressure sensor, too.

  • Set up Tailscale as exit node to your local network.

    Make sure that your network is not standard 192.168.0.x or 192.168.1.x IP address range, but something like 192.168.101.x so you don't have IP conflicts when accessing from a friend's house or workplace wifi.

    Set up Nginx to redirect your home server IP (eg. 192.168.101.5) to the correct port for your dashboard like Heimdall or Dashy.

    That's it. Works like a charm for me if set up this way.

    Addendum: if you have trouble on Android, disable MagicDNS.

  • No, it isn't. OS and app volume controls are not implemented on driver level, but in each application individually, or you wouldn't be able to change OS volume and in-app volume independent of each other. It's simple math, multiplying audio sample values with a coefficient, best done in 32 bit floating point.

    The question is not whether to do the math at driver level or in the userspace. The question is: if the user sets their volume slider to the middle, what value that coefficient should be? Most apps use simple linear correlation (middle point halves values which is 6 dB of attenuation or -6 dB(FS)) which is not how human hearing works. Log volume control would have the middle point at, eg, -40 dB(FS) and zero point at -80 dB(FS), giving psychoacoustically useful range in both halves of the bar. This is how analog volume controls on amplifiers work (not exactly so, but pretty close).

    Driver level volume control can be done, but then you'd need to open your sound card control app and set it there. It would be an addition to OS and app volume controls. It would not be tied to OS or in-app volume controls or affected by standard multimedia keys on your keyboard. And if you decide to do OS volume control at driver level, in-app volume controls would still need to exist and be at the mercy of the app devs competency at implementing it.

  • Implementing proper logarithmic volume controls and defaulting them to -20 dB(FS) would be great. But the math involved is slightly more complicated than the simplistic "multiply everything with a coefficient between 0 and 1" so devs won't bother (if they even know about logarithmic volume controls at all).

    I did logarithmic volume slider in Jscript for foobar2000 using a Jscript GUI plugin and it was not too difficult, but not straightforward either. Getting the button states and scaling to work correctly was more difficult and I never solved some annoying bugs. That was the first and the only "programming" I've ever done in my life.