Indirectly is doing a lot of work there. The US is an extremely disenfranchised place, and the choices are both pro-capital and will never actually represent the people in any meaningful sense. This liberal individualism framing only serves to bolster nationalism and divide groups when what we really need to be doing is recognizing our shared goals, with "we" being the international "we", and figure out who our enemies really are.
Equating the two seems pretty "radically centrist". Also I'm not so sure that's accurate given that the far right continues to gain legal political power in the EU (and the US for that matter).
I mean, if they relinquish their ownership of the plane and joined in with some sort of council that determined how to manage such assets I bet everyone claiming to be an anarchist would be fine with it. Anarchy as a political ideology doesn't mean no rules, it means no rulers.
I would not call it irresponsible. If you have a big, long running project you're going to want to develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow, but switching vendors can require redoing work that was built over years.
> you're going to want to develop complex pipelines and build processes to help with development and testing
Opinion: Complex build processes are great. Complex _pipelines_ are a trap. I'm in a position to see the output of a lot of teams at a very large company. The teams that have complex build processes _that they can run locally_, and then have some trivial CI yaml to run the build, are doing great.
The teams that designed their build around CI are brittle and eventually end up in a state where they can _only_ do some parts of their build on CI.
IME it's worth it to set very hard boundaries shaped like: (1) Everything needs to be able to be run locally (usually in a devcontainer), (2) CI config shall be stupid simple. If you have more than like two lines in a script section, it goes into a Tools/Build script file that must work locally and is just called in a one-line CI script.
#1 guarantees you can operate without CI, and #2 guarantees you can move CI providers trivially.
>develop complex pipelines and build processes to help with development and testing. This will save a lot of time and create a more consistent workflow,
Beware the trap of making the pipeline so complicated it's like code except you can't debug or unit test like regular code, and it takes an hour between attempts to see if a change worked.
If only we had a way to run code in a pre-defined isolated environment that can hide most of the differences of the actual hardware...
Oh, we do have Docker/Podman?
Then why not use _them_ to define your build pipelines? Bonus points: you can run them locally without tearing out your hair. And you can use normal scripting languages and task runners (taskfiles, good old makefiles, Ninja, etc.) for sequencing.
We are a franchisor the owns 2 concepts, both of which are thrift stores aimed at different demographics. We write all of our software in-house and its actually a surprisingly "fun" context.
The business had pretty questionable (read: bad) software for a long time, then came under new management a few years ago. I joined just under two years ago and since then we've been modernizing the code with an eye to move it off of the in-store servers its running on currently and into the cloud. That is complicated by the fact that the franchisees are not used to certain things, like really needing to have reliable internet with a failover, so we've had to (or had the opportunity) do some serious hardening on the in-store servers and how we deploy software to them. We've switched them all to immutable OSes, added a bunch of telemetry, and added some new services that are slowly eating the old ones' responsibilities and will be much easier to move to the cloud.
Also the winters are ok but not as nice as they used to be. I grew up here so I remember when they were extremely snowy and I miss that, now they're fairly grey and mild.
Same here! The slight difference being I'll just do something else for money and code purely for fun if hand written code stops being economically viable. I'll highly confident that won't happen though.
In my experience moving from GH to Forgejo was trivial, largely because the actions are mostly compatible and importing the repos can be automated. The amount of time it took was definitely less than the 5-8 hours of downtime that GHA had yesterday.
reply