• 0 Posts
  • 7 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle

  • Pulumi code ends up looking like a DSL anyway with all the stuff you end up using from the top-level pulumi package to do anything vaguely complicated.

    Only now, compared with Terraform, you need to worry about resource ordering and program flow, because when you have a dependency between resources, the resource object you depend on has to be instantiated (within the program flow, I mean - Pulumi handles calculating the ordering of actual cloud resource creation) before the dependent resource. This gets old really quickly if you’re iterating on a module that creates more than a few interdependent resources. So much cut, paste, reorder. FWIW CDK has the same issue, and for the same reason - because it’s using a general-purpose programming language to model a domain which it doesn’t fit all that well.

    I like Pulumi and it’s got a lot going for it, especially if you have complex infrastructure requirements. You get a bunch of little quality of life enhancements that I wish Terraform would adopt, like cloud state management by default, and a built-in mechanism for managing secrets in a sane way. Python/TypeScript etc. modules are much more flexible than Terraform modules, and really help with building large chunks of reusable infrastructure. The extra programmability can be useful, though you need to be extra-careful of side-effects. You get more power, but you also get some extra work.

    But for most people deploying a bit - or even quite a lot - of cloud infrastructure, Terraform is honestly just easier. It’s usually some fairly simple declarative config with some values passed from one resource to another, and a small amount of variation that might require some limited programmability. Which is exactly what Terraform targets with HCL. It’s clear to me that Pulumi sees this too, since they introduced the YAML syntax later on. But IMO HCL > YAML for declarative config.


  • Do we have to bring this up again? It’s just boring.

    systemd is here and it isn’t going anywhere soon. It’s an improvement over SysV, but the core init system is arguably less well-designed than some of the other options that were on the table 10 years ago when its adoption started. The systemd userspace ecosystem has significantly stifled development of alternatives that provide equivalent functionality, which has led to less experimentation and innovation in those areas. In many cases those systemd add-on services provide less functionality than what they have replaced, but are adopted simply because they are part of the systemd ecosystem. The core unit file format is verbose and somewhat awkward, and the *ctl utilities are messy and sometimes unfriendly.

    Like most Red Hat-originated software written in the last 15 years, it valiantly attempts to solve real problems with Linux, and mostly achieves that, but there are enough corner cases and short-sighted design decisions that it ends up being mediocre and somewhat annoying.

    Personally I hope that someone comes along and takes the lessons learned and rewrites it, much like Pulseaudio has been replaced by Pipewire. Perhaps if someone decides it needs rewriting in Rust?


  • The WiFi card is probably a Realtek 8852AE, which has become very common in laptops since 2021. Unfortunately Realtek driver support tends to lag quite a bit.

    If you want to run Ubuntu Desktop 22.04, then you’re probably best off waiting a few weeks for the Ubuntu Desktop 22.04.4 point release. It’s due sometime this month. It will boot and install an “HWE” (Hardware Enablement) kernel and drivers, that are based on the kernel from Ubuntu 23.04, and therefore should work out of the box with your WiFi card.

    While it’s possible to upgrade an existing Ubuntu 22.04 installation with the latest HWE kernel, doing it by downloading the relevant packages on another machine and moving them across using a USB stick is going to be somewhat frustrating if you’ve not done it before. You’ll certainly learn a few things, but it may not be an enjoyable experience. I’m a grizzled Linux veteran, and I’m pretty sure I’d end up forgetting to download one or more packages and having to swap back and forth between machines.

    In the meantime, I would just continue to use Ubuntu 23.04. In fact, if it was me, I would probably just stick with 23.04, upgrade to 23.10 and then subsequently 24.04 when they become available. What you do once you’re on the 24.04 LTS release is up to you. By that time, other distros will probably also work out of the box too.


  • At least for me, there is a big difference between naming things at home and naming things for work.

    Work “pet” machines get systematic names based on function, location, ownership and/or serial/asset numbers. There aren’t very many of them these days. If they are “cattle” then they get random names, and their build is ephemeral. If they go wrong or need an upgrade, they get rebuilt and their replacement build gets a new random name. Whether they are pets or cattle, the hostnames are secondary to tags and other metadata, and in most cases the tags are used to identify the machines in the first instance, because tags are far more flexible and descriptive than a hostname.

    At home, where the number of machines is limited, I know all of them like the back of my hand, and it’s mostly just me touching them, whimsical names are where it’s at.


  • marmarama@lemmy.worldtoSelfhosted@lemmy.worldWhat is your machine naming scheme?
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Ungulates. Because who doesn’t like a hoofed animal?

    My client machines are even-toed ungulates (order Artiodactyla) and my servers/IoT machines are odd-toed (order Perissodactyla). I’m typing this on Gazelle. My router is called Quagga, both after the extinct zebra subspecies and the routing protocol software (I don’t use it any more but hey, it’s a router).

    Biological taxonomy is a great source of a huge number of systematic (and colloquial) names.


  • It is worse than uncompressed, but 990Kbps LDAC is the closest codec to totally transparent I’ve heard for Bluetooth audio. AptX HD is nearly as good to my ears, and is better than 660Kbps LDAC. The differences are very small though, especially when compared with the differences on the analog side, e.g. the amp, and particularly the headphone design.

    Apple side-steps the problem by, at least when you’re listening to Apple Music, simply sending the AAC stream as-is to the headphones and has them decode the audio. I don’t know why that isn’t a more common approach.

    I’m still somewhat bemused that we’re talking about Bluetooth codecs at all. It surely can’t be that difficult technically to get 1.5Mbps actual throughput on Bluetooth and simply send raw 16-bit/44.1Khz PCM. 2.4Ghz WiFi is capable of hundreds of times that speed. Bluetooth has been stuck at the same speeds for decades.