• 0 Posts
  • 294 Comments
Joined 3 years ago
cake
Cake day: June 21st, 2023

help-circle







  • You could put it into the archinstall script and just never finish the installation if there is no age set. You could also prevent a user from logging into an account that has no age set, this could be achived by modified core packages in the base package.

    My (rather limited) understanding is that Arch can be installed both without the archinstall script and without a user. Also, the rest of your comment covers how stupid it is to require a value anyway since people can put whatever they want.

    Outside of that, it’s all open source. It’s possible to fork and remove the field entirely from an install script, distro, or even systemd itself.

    Nobody can enforce this in the open source world. This is honestly the strongest argument for an open source exemption in these laws. It cannot be enforced on open source OSs.







  • The success rate of main branch builds compounds this further. It has fallen to 70.8%, its lowest in over five years – 30% of attempts to merge code for production are now failing.

    The integration bottleneck finding is credible. If you’re generating code faster than your team can review and integrate it, that’s a genuine problem this data is consistent with.

    I disagree here. If more attempts are failing, then more attempts are needed to merge a branch. If the pipeline is running more and fewer branches are merging, it’s also possible that people need to go through more revisions to merge their code than they needed to before.

    People using AI to write their entire PR will find that fixing issues with it takes more work. They often don’t know how the PR works. I wouldn’t be surprised if this resulted in PRs taking longer to merge as a result, which would contradict CircleCI’s claims of teams benefiting from AI.

    I believe the report has insufficient data to draw any meaningful conclusions. The data is interesting, at least.


  • This decoupling of commands from effects is interesting, but I don’t think I’d use it in most places. In this specific example, passing in an interface for an API client (or whatever other thing you want to call) lets you create a mock client and pass that in during testing, and different environments should be configured differently anyway.

    There is one place I’d consider this though, and it’s incredibly specific: a MTG rules engine. Because of replacement effects, triggered abilities, and so on, being able to intercept everything from starting turns to taking damage means you can apply the various different game effects when they come up rather than mixing that logic up all over the codebase. I’m tempted to try this and see if it works, actually.


  • On the contrary, I have a 1440p 120Hz primary monitor and a 4k 60Hz vertical side monitor, and I can only seem to make that setup work with Wayland. I’ve been using only Wayland this whole time as a result.

    As for all your issues with it:

    • I’m able to record my screen just fine with multiple applications. Are you trying to write your own screen recorder, or use existing ones?
    • I have not had any issues with fullscreen. If anything, it works better for me than Windows. (I can’t compare it to X11 because I can’t use X11.)
    • I don’t really understand what you mean by having a clipboard. Do you not have one on Wayland somehow?
    • Hotkeys seem to work for me, so I’m confused here too.
    • I’m not too sure what you mean by “manufacture inputs” but my keyboard supports programmable macros and that works for me, though I believe that works by flashing the keyboard instead of through software.
    • Programs I use often use their own themes regardless of Wayland/X11 so the client-side decorations doesn’t matter nearly as much to me. I would like it to be more consistent, but that’s on both sides (Wayland+application devs) to figure out.

    The rest of these aren’t issues I’ve had to deal with at all, but I can see them coming up. Wayland does have some issues, but nothing I’ve come across that’s major enough to bother me all that much.



  • What I usually push for is that every CI task either sets up the environment or executes that one command™ for that task. For example, that command can be uv run ruff check or cargo fmt --all -- --check or whatever.

    Where the CI-runs-one-script-only (or no-CI) approach falls apart for me is when you want to have a deployment pipeline. It’s usually best not to have deployment secrets stored in any dev machine, so a good place to keep them is in your CI configs (and all major platforms support secrets stored with an environment, variable groups, etc). Of course, I’m referring here to work on a larger team, where permission to deploy needs to be transferrable, but you don’t really want to be rotating deployment secrets all the time either. This means you’re running code in the pipeline that you can’t run locally in order to deploy it.

    It also doesn’t work well when you build for multiple platforms. For example, I have Rust projects that build and test on Windows, MacOS, and Linux which is only possible by running those on multiple runners (each on a different OS and, in MacOS’s case, CPU architecture).

    The compromise of one-script-per-task can usually work even in these situations, from my experience. You still get to use things like GitHub’s matrix, for example, to run multiple runners in parallel. It just means you have different commands for different things now.