> Why, again, software in the Linux world has to be packaged for multiple distributions?
Because a different distribution is a different operating system. Of course, not all distributions are completely different and you don't necessarily need to make a package for any particular distribution at all. Loads of software runs just fine being extracted into a directory somewhere. That said, you absolutely can use packages for older versions of a distribution in later versions of the same distribution in many cases, same as with Windows.
> And to the boot, you don't have to go through some Microsoft-approved package distribution platform and its approval process: you can, of course, but you don't have to, you can distribute your software by yourself.
This is the same with any Linux distribution I've ever used. It would be a lot of work for a Linux distribution to force you to use some approved distribution platform even if it wanted to.
It takes some work, but it's entirely possible to both use Docker and run individual tests with breakpoints (in a Docker container) in your IDE. For example, you can attach VS Code to a running container.
Yes, but it creates a restrictive and fragile happy-path when the aim imo should be closer to a lab/woodshop where you can take it apart however you like and need for the moment.
Ripping DVDs is pretty easy these days, and you can buy used for good deals.
This is of course more expensive, since you have to buy a large storage drive, a disc reader and discs. But you have more control and rights with physical media than streaming; in practice no one can take your bits away.
If you are less scrupulous there are of course, other sources.
I believe the difference is that in your example file.go needs to live in the repo (or created by a previous step:) whereas reading from stdin allows writing the logic in the .yaml itself, and thus is subject to uses: or other reuse tricks
I understand the arguments for putting more things in scripts instead of GHA YAML. However, I also like that breaking things up into multiple YAML steps means I get better reporting via GitHub. Of course I could have multiple scripts that I run to get the same effect. But I wish there was a standard protocol for tools to report progress information to a CI environment. Something like the Test Anything Protocol[0], but targeted at CI/CD.
GitHub Actions workflow commands[1] are similar to what I'm thinking of, but not standardized.
It's frustrating that we're beholden to Github to add support for something like this to their platform, especially when the incentives are in the wrong direction— anything that's more generic and more portable reduces lock-in to Actions.
You're also adding an extra build step that by its nature can't run in CI since it generates the CI pipelines. So now you need some way to keep your Dhall and YAML in sync. I suppose you could write one job in YAML that compiles the Dhall and fails the build if it's out of date, but it seems like a lot of extra work for minimal payoff.
Instead, if you want to stay away from YAML, I'd say just move as much of the build as possible into external scripts so that the YAML stays very simple.
> To the greatest extent possible, do not use any actions which install things.
Why not? I assume the concern is making sure development environments and production use the same configuration as CI. But that feels like somewhat of an orthogonal issue. For example, in Node.js, I can specify both the runtime and package manager versions using standard configuration. I think it's a bonus that how those specific versions get installed can be somewhat flexible.
You're right, I guess I should reword it to "not lose any unnecessary points." I remember a level like that with a queen in just the right spot that any legal move was attacked, but moving left/right changed your options for later moves.
I see it as just the builder pattern that's pretty common in languages like Java. `container` is constructing the builder itself and eventually `terminal` (or other commands) use the state that has been incrementally built up in the builder to actually do something with the container.
It's super fun to mess around. I think i found a bug - https://imgur.com/BRwst17 - in this setup kick triggers on red instead of green? Or am i tripping?
That doesn't seem to happen for me. If you lower the BPM (the value on the right is a non-obvious text input) does it still seem to trigger incorrectly?
Because a different distribution is a different operating system. Of course, not all distributions are completely different and you don't necessarily need to make a package for any particular distribution at all. Loads of software runs just fine being extracted into a directory somewhere. That said, you absolutely can use packages for older versions of a distribution in later versions of the same distribution in many cases, same as with Windows.
> And to the boot, you don't have to go through some Microsoft-approved package distribution platform and its approval process: you can, of course, but you don't have to, you can distribute your software by yourself.
This is the same with any Linux distribution I've ever used. It would be a lot of work for a Linux distribution to force you to use some approved distribution platform even if it wanted to.
reply