Skip Navigation

Posts
7
Comments
741
Joined
2 yr. ago

  • The vastness of the ecosystem built around Apple products cannot be understated. You can't just change the iPhone port every few years.

    Ditching the 30-pin adapter created no small degree of controversy. Though the device itself got favorable reviews, the New York Times’ tech columnist at the time called it “not just a slap in the face to loyal customers” but a “jab in the eye.”

    The Lightning connector was introduced on September 12, 2012, with iPhone 5. And there was so much controversy around it that they publicly committed to using it for at least 10 years.

    The USB-C spec was not finalized until nearly two years later, in August 2014.

    I can't fault a company for activity committing to a decade of compatibility with peripherals. And I certainly can't fault them for avoiding the disaster called Micro USB.

  • You basically just made the case for exactly why.

    Programs should be using the system resolver, not parsing that file.

    The system resolver should have predictable behavior. But if other programs are doing their own DNS resolution (or otherwise predicating their functionality) based directly on the contents of resolv.conf then their behavior will not always be consistent with the system resolver (or with how the sysadmin intended things to function).

    And that can break things in subtle, unpredictable ways, which is always a headache.

    Thus, on some modern systems, resolv.conf simply declares the local systemd-resolved instance (i.e. 127.0.0.1) and nothing else.

    A single global resolv.conf file also will not let you configure different behavior based on interface or on network namespace. Want to ensure DNS lookups for specific apps occur only through your VPN-specific DNS servers but all other apps only use the normal system resolvers (i.e. no leaking from either side of the divide)? Want to also ensure DNS lookups for those specific apps fail when the VPN is down (again, as opposed to leaking)? systemd-resolved has your back.

    And before anyone asks, yes, I am aware there are other, more crude and convoluted ways to do that with e.g. iptables (just like you can use crude, inconsistent init.d spaghetti scripts to manage services). It's just one single real-world example.

    A single global resolv.conf file also will not let you configure different behavior based on interface or on network namespace.

    The point is to configure everything using consistent, predictable configuration files and syntax, and to ensure consistent, predictable behavior.

    But if you ultimately still want resolv.conf.d back, then your distro of choice undoubtedly provides a way to do so.

  • It's okay. It's an actual quote from Ray:

    In a statement announcing his brother's death, brother Ray alluded to a familiar joke about the weekly puzzlers they always featured in the show.

    "Turns out he wasn't kidding. He really couldn't remember last week's puzzler," Ray said. "We can be happy that he lived the life he wanted to live; goofing off a lot, talking to you guys every week and primarily laughing his ass off."

  • Cloud-init is fairly well documented:

    https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v2.html#nameservers-mapping

    But if you do not need it (and if you're configuring DNS by hand, it doesn't sound like you do), you can disable it entirely:

    https://cloudinit.readthedocs.io/en/latest/howto/disable_cloud_init.html

    resolv.conf itself should be managed by systemd-resolved on any modern Ubuntu Server release. And that service will use the DNS settings provided by netplan.

    With cloud-init disabled, you should have the freedom to create/edit configuration files in /etc/netplan and apply changes with netplan apply.

  • That's more of Brother doing things correctly. Mine automatically shows up on all my Windows systems too.

  • I guess he really did have trouble remembering last week's puzzler.

  • You're doing great. I'm proud of you.

  • Clearly if you turn the image upside-down, it is a Whale-Gnome-Dustbuster-Pharaoh in the architectural style of the Goa'uld/Ancient Ancients with a blowhole-mouth surprise.

    But I'm leaning toward Dustbuster, now that we know it's Hoovering up ships.

  • Picardi B can't hurt you, they aren't real.

  • I feel compelled to point out this important bit of context for anyone who doesn't read the paper:

    Overall, based on the four environmental indicators used in this study, home-washed reusable nappies have the potential for the least environmental impact if washed in a water-efficient front￾loading washing machine in cold water, and line-dried.

    The UK study similarly found that colder water and line-drying would sufficiently reduce the carbon footprint to a lower level than disposables.

    But seriously? Who does that?

    For regular clothing, where you can use a more powerful detergent? Sure.

    But for something that goes directly against your child's most sensitive skin, which will need to be laundered with gentle detergent?

    Maybe we can find a paper on how to do all that without heat but with proper sanitation? Remember, laundry detergent is designed to clean, but not necessarily to sanitize.

  • I'll see if I can find some better ones. This was just the first one I plucked out of a random citation, because I knew I would get eviscerated without one. But I've been seeing the advice about disposables as far back as I can remember. It was even a trick question in an eco quiz when I was a child back in the 90s (i.e. "Which of these things are better ecological choices?").

    Interestingly the 2006 study itself is an updated version. Disposables did even better in the 2006 study than in the older one: Due to advances in manufacturing and in materials science, they were able to start producing them using less material (which decreases the carbon footprint during manufacturing, shipping, and disposal).