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

help-circle





  • What? Tech companies the world over have people on 24/7 on-call rotas, and it’s usually voluntary.

    Depending on the company, you might typically do 1 week in 4 on-call, get a nice little retainer bonus for having to have not much of a social life for 1 week in 4, and then get an additional payment for each call you take, plus time worked at x1.5 or x2 the usual rate, plus time off in lieu during the normal workday if the call out takes a long time. If you do on-call for tech and the conditions are worse than this, then your company’s on-call policies suck.

    I used to do it regularly. Over the years, it paid for the deposit on my first house, plus some nice trips abroad. I enjoyed it - I get a buzz out of being in the middle of a crisis and fixing it. But eventually my family got bored of it, and I got more senior jobs where it wasn’t considered a good use of my energies.

    Your internet connection, the websites and apps you use, your utilities - they don’t fix themselves when they break at 0300.

    If TSMC’s approach to on-call is bad, then yeah, screw that. I don’t see anything in the article that says that one way or the other. But doing an on-call rota at all is a perfectly normal thing to do in tech.


  • 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.





  • Nvidia drivers have (slightly) more timely support for the latest cards, and more mature support for non-3D uses of the GPU, especially scientific computing. To a large extent they are the same code as the Windows drivers, and that has positives in terms of breadth and maturity of support.

    For everything else, the AMD drivers are better. Because they are a separate codebase from the Windows drivers, and are part of the de-facto Linux GPU driver stack Mesa, they integrate much better into the overall Linux experience, especially around support for Wayland. Unless you have an absolutely bleeding-edge card, they “just work” more often than the Nvidia drivers. If you like doing serious tinkering on your Linux system, then the AMD drivers being fully integrated and having the source available is a major win. Also, it used to be that the Nvidia drivers did a much better job of squeezing performance out of the hardware, but today there’s very little in it, and the AMD drivers might even be a little more efficient.

    I’ve got both AMD and Nvidia GPUs currently in different machines, and I much prefer the Linux experience with AMD. I don’t think I’ll be buying another Nvidia GPU unless the driver situation changes significantly.

    FWIW I don’t stream so I can’t comment on the exact situation, but I have used the video encode hardware on AMD cards via VAAPI and it was competent and much faster than x264/x265 on the CPU. I think OBS has a plugin to use VAAPI (which is the “standard” Linux video decode/encode acceleration interface that everyone but Nvidia supports).