71–80 of 152 posts
Earlier quoted context omitted.
If only there was a decentralized system to allow version management of code.
Sadly, GitHub doesn't store its value-add assets within the repository itself; so all of the PR conversations, Gists, Issues, and so forth aren't within git itself.
My repos were coming up as 404s. I was wondering if I had been canned...
The "nothing to see here" approach to access control has a lot of weird culture-consequences. I wish software would just address me like the peasant that I am, rather than trying to gaslight me into believing that my artificially limited world is the whole one.
Earlier quoted context omitted.
I know this a greybeard's fantasy and that most people working today were trained not to bother, but: important things should not have GitHub as a failure point . Hobby projects and today's work? Sure. Point straight at GitHub and hack away. And when it goes down, get yourself a coffee. But everything that's anywhere near production should have already pointed those github requests to a mirror or other tool in your o…
It's not that black and white. Where do you draw the line on what can and can't be a failure point? My cloud provider is probably an acceptable point. If every AWS region goes down I'm not going to have a spare cloud provider. What about an auth provider? Do I need a backup there? What about CI, do I need multiple CI systems? 3rd party search services, realtime messaging services, the list goes on. For 1% of systems,…
Everything you mentioned can be replaced. Your source code can't.
Github is becoming too important. A routine backup system is needed, something like archive.org, that backs up important Github projects.
My repos were coming up as 404s. I was wondering if I had been canned...
The "nothing to see here" approach to access control has a lot of weird culture-consequences. I wish software would just address me like the peasant that I am, rather than trying to gaslight me into believing that my artificially limited world is the whole one.
Earlier quoted context omitted.
In theory, the code is there, but putting a project back together in a hurry after trouble at Github is non-trivial. Especially if the build process uses proprietary stuff such as "GitHub actions". The issues and discussions are all Github-only, too.
It’s crazy that there is no common CI spec. Every single platform is completely different. Last time I tried Act it had some pretty severe limitations. Perhaps I should take it for another spin.
In CI, it now just needs to run the scripts in the correct order.
Earlier quoted context omitted.
In theory, the code is there, but putting a project back together in a hurry after trouble at Github is non-trivial. Especially if the build process uses proprietary stuff such as "GitHub actions". The issues and discussions are all Github-only, too.
It’s crazy that there is no common CI spec. Every single platform is completely different. Last time I tried Act it had some pretty severe limitations. Perhaps I should take it for another spin.
What's needed is a formally defined CI spec(s). Common is bad for the same reason any monopoly is bad. Formally-defined solves some of the same problems common is solving where it's important to be protected from random failures of the sole provider, but it also makes it, at least theoretically, easier to have multiple providers.
This is similar to how C is different from Make. C is a standard that anyone can implement, while make is a weird language defined by its implementation that some tried to reimplement, but by doing so only increased the insanity of compatibility issues.
Of course there were multiple attempts to make common / standard definitions for general-purpose automation tools. Make is one of those, Ant is another one, and there's plenty more. I'm not sure why none really sticks around to the point of becoming a universally accepted tool / standard. Some reasons I can think about are: languages build special-purpose automation tools around their implementation which are often the selling point of the language, an attempt to sell it to developers, so the authors are disincentivized from making them general-purpose. There isn't a consensus on what such tools should do and what kind of guarantees they need to offer. Some such guarantees may come with a price, sometimes very steep price, so would be hard to sell. Eg. something like tup offers highly reliable reproducible and isolated builds, but at a cost of complexity and resources, whereas something like Make offers no guarantees, but is easier to get started with and to be productive.
Maybe it could be possible to extract just the component of CI that deals with the "skeleton" of automation, defining abstract tasks, dependencies between them etc... but then immediately there'd be plenty of systems that'd try to complement this automation with their own (proprietary) extensions which would circle us back to the initial problem...
My repos were coming up as 404s. I was wondering if I had been canned...
The "nothing to see here" approach to access control has a lot of weird culture-consequences. I wish software would just address me like the peasant that I am, rather than trying to gaslight me into believing that my artificially limited world is the whole one.
My repos were coming up as 404s. I was wondering if I had been canned...