Forced price matching could be considered a abuse of their position. If a dev cannot sell on another store for less (even if that platform takes a smaller cut) then that makes reduces the need for others to use a different platform to get a cheaper deal. Devs cannot use pricing to save you some money while drawing you to a platform that gives them a larger margin. All of which means that there is less incentive for valve to reduce their cut of the sale to be more competitive. This is what some lawsuits against valve are arguing ATM I believe.

Most people I know don’t look outside of steam for games. Might be a regional thing. But there are a lot of people that just don’t care about the other stores. At least not while steam offer a good experience.

You can choose to buy new things on other platforms. But you lose access to everything you bought on steam if you choose not to use them anymore. That is a form of locking to their platform. You cannot just move you library to another platform.

Sorry badly worded on my part. They can use other platforms alongside steam. I really meant they cannot use them instead of steam without losing a massive audience. And likely making their game unprofitable. At least if they are not a very large game studio already.

And then if steam is pushing restrictions on what they can do on other stores then that is edging into the relms of abusing their monopoly.

Yeah, Steam may be effectively a monopoly, but it’s because nobody else really wants to compete with them at their level.

Steam has two types of customers. Us the gamers where we can decide which platform to use. They have an effective monopoly on us because they provide a good service. But with a large game library we are locked into steam as well and cannot just switch to a different platform. If valve ever did decide to be evil then we are screwed.

But developers are also customers of valve. And this is arguably where valve makes their money. They take a cut from the developers sales. Devs cannot just use a different platform without cutting out a huge userbase. This gives valve a real monopolistic control over developers.

Its hard to argue that 2 config files both multiple lines long is simpler then a single line in an existing file. Adding a service to cron is just simpler. But adding all the extra bit you are going to want on top increases the things you need to learn to do and configure correctly.

IMO systemd timers are simpler to get right at a little bit more of an upfront cost to learning how they work. But cron is still simpler to just get something working without caring that much. I still find that ends up biting you in the longer term though though all the missing features you need to add manually on top of that one basic line you added.

Cron jobs are nice and simple to create. Until they go wrong then they are a pain in the ass. You need to manage logging yourself. If you forget you root mail will fill up your disk and crash the system. If you forget the mailto setting. If you remember it you justlose all logs and have no clue why something is not working. You need to redirect the output to a logfile yourself. And then risk filling up the disk with logs unless you remember to also set up logrotate. And you then still don’t know when something last ran or if it ran successfully.

So many traps and that is just the logging side of things.

My favourite: The code does not work. You make a change, it breaks more. You undo that mistake: it now works.

That does not stop things from stealing your data.

Yeah… Ubuntu packages are never up to date on release date. They freeze them months before so they can iron out any bugs with the versions they picked. You don’t pick Ubuntu or any point release distro to get up to date packages.

Probably something to do with their main package deleting the pacman lock file so it can run a nested pacman update command… Which means two pacman instances running at the same time and nothing stopping other ones after that nested one has completed.

I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c

a everyday joe would do

Go to work, work, go home. Wait for the end of the week/month for their next paycheck.

Most people already have more then a dollar and more then 24 hours to earn money. If schemes like that really worked then why would so many people do anything else?

BREAKING NEWS: Girl gets home safely after night out. More at 11.

Yes. They can. But they do not mix well with required checks. From githubs own documentation:

If a workflow is skipped due to path filtering, branch filtering or a commit message, then checks associated with that workflow will remain in a “Pending” state. A pull request that requires those checks to be successful will be blocked from merging.

If, however, a job within a workflow is skipped due to a conditional, it will report its status as “Success”. For more information, see Using conditions to control job execution.

So even with github actions you cannot mix a required check and path/branch or any filtering on a workflow as the jobs will hang forever and you will never be able to merge the branch in. You can do either or, but not both at once and for larger complex projects you tend to want to do both. But instead you need complex complex workflows or workflows that always start and instead do internal checks to detect if they need to actually run or not. And this is with github actions - it is worst for external CICD tooling.

Don’t think any game has the same support doom has. Doom has become a benchmark of sorts so gets ported to the strangest of places. Not normally places you would bother to port any game. It is done for the challenge of the port rather than any practical reason.

There are tonnes of games that could run in the same places as doom, many could run in far more places. But doom is complex enough to be an interesting challenge while being simple enough to run on very limited hardware. And has been open sourced while being a classic icon which makes it attractive to be a benchmark for getting to run in the weirdest of places.

If you have folderA and folderB each with their own set of tests. You don’t need folderAs tests to run with a change to folderB. Most CI/CD systems can do this easily enough with two different reports. But you cannot mark them both as required as they both wont always run. Instead you need a complicated fan out pipelines in your CICD system so you can only have one report back to GH or you need to always spawn a job for both folders and have the ones that dont need to run return successful. Neither of these is very good and becomes very complex when you are working with large monorepos.

It would be much better if the CICD system that knows which pipelines it needs to run for a given PR could tell GH about which tests are required for a particular PR and if you could configure GH to wait for that report from the CICD system. Or at the very least if the auto-merge was blocked for any failed checks and the manual merge button was only blocked on required checks.

One problem is GHs auto-merge when ready button. It will merge when there are still tests running unless they are required. It would be much better if the auto merges took into account all checks and not just required ones.

Yeah there are ways to run partial tests on modified code only. But they interact poorly with GH required checks. https://github.com/orgs/community/discussions/44490 goes into a lot more detail on similar problems people are having with GH actions - though our problem is with external CICD tools that report back to GH. Though it does look like they have updated the docs that are linked to in that discussion so maybe something has recently changed with GH actions - but I bet it still exists for external tooling.