3 ms·

> With a simple shell script and a bit of configuration you can set up a box that will check some email and act after detecting some kind of commands directed a

by plonk 4y ago

> With a simple shell script and a bit of configuration you can set up a box that will check some email and act after detecting some kind of commands directed at it. Yes but I don't see how using a mailing list would improve anything. You'd just end up re-writing all GitLab features on top of a different database and interface, and the scaling issues would remain. This seems like more of a centralisation-vs-self-hosting issue. > That being said, I'm 90% sure the GP is sarcastic, trying pull reductio ad absurdum on people who will almost assuredly come here commenting that "the community" should "abandon centralized services" in favor of this or that pet-project. Makes sense but I didn't interpret it that way.

kkfx 4y ago
A ML is personal. You can move it from a hoster, potentially yourself included, to another. You can't move GitHub because it's not an implementation of something standard but a proprietary service... That's the issue. You ML can be down, other 99% of FLOSS ML projects will not even notice the downtime, if all are on a service and the service goes down all are affected. Your ML is yours, a political issue between two government will not block you, GH can be blocked and actually was blocked and is still for various countries and reasons NOT directly related to individual projects on it. And so on. Peoples these days tend to think that mega-IT-giants will always be up and running, so being on their shoulder is a guarantee of stability, actually is the contrary is a threat.
- plonk 4y ago
  That's an argument for self-hosting, not for mailing lists. What you're describing is GitLab.
  - kkfx 4y ago
    ML can be both self-hosted or hosted by third party, being a standard thing you are not tied to any specific player. Your "public upstream repo" is on your domain, no matter who bound it right now.
    - plonk 4y ago
      It took me days to set up my team’s CI/CD pipeline with GitHub’s existing features. If I started from a simple mailing list, it would take months of full-time work to add automated build steps with dependencies between steps, caching, secure secret management, proper authentication, a practical issue database, and link that to my git repo. At that point, I would have a completely new product that takes a full-time maintainer and has the same complexity as the big players. It would be more efficient to fork GitLab. I think you don’t realize how wasteful that is. And what’s the point? There’s already a well-maintained FOSS self-hosted solution that benefits from not being based on antiquated technologies.
      - kkfx 4y ago
        At that point you might have discovered not needing at all 99% of DevOps concepts, and that probably they exists because they help some making profits not because are good ideas. In that terms, it's OT and very long to discuss here, my opinion is that's about time to ERASE 30+ years of IT crappy history to start back at pioneering time Xerox PARC for instance where ALL we use today was invented and implemented far better than now, where their antiquated technologies are actually far more advanced than most we use everyday calling them new and advanced. An OS must came back to a unique fully-integrated environment, with a single programming language, no matter if Lisp, Smalltalk or something else, applications simply do not exists, are just built-in functionality we develop inside the system, deploy is just pushing code to available instances etc. Such VERY ancient model is actually far more advanced than modern one, demand far less efforts and resources giving back far more. It's not there because at a certain point in time IBM decide that compartmentalization and crap made profit and modern IT giants understand that very well going far beyond.
- klibertp 4y ago
  Oh boy, I was wrong. You were serious? I mean, I myself am often telling other programmers to study history of the field, pointing out that a lot of "ground-breaking" ideas were invented in the '70s, but trying to bring those ideas as realized back then to today's world is not going to work. Both USENET and self-hosted mailing lists died for a reason: it's too cheap to spam them and with increasing number of users, the probability of someone wanting to fuck them up approaches 1. Self-hosting is a good thing, but you can get halfway there by simply having a backup hosting from an unrelated entity. Actually, if you look at GNU Emacs development that I'm familiar with, it's conducted over a mailing list and a self-hosted git repo, but that repo is mirrored and backed up on GitHub...

by plonk 4y ago

kkfx 4y ago

A ML is personal. You can move it from a hoster, potentially yourself included, to another. You can't move GitHub because it's not an implementation of something standard but a proprietary service... That's the issue. You ML can be down, other 99% of FLOSS ML projects will not even notice the downtime, if all are on a service and the service goes down all are affected. Your ML is yours, a political issue between two government will not block you, GH can be blocked and actually was blocked and is still for various countries and reasons NOT directly related to individual projects on it. And so on. Peoples these days tend to think that mega-IT-giants will always be up and running, so being on their shoulder is a guarantee of stability, actually is the contrary is a threat.

plonk 4y ago
That's an argument for self-hosting, not for mailing lists. What you're describing is GitLab.
- kkfx 4y ago
  ML can be both self-hosted or hosted by third party, being a standard thing you are not tied to any specific player. Your "public upstream repo" is on your domain, no matter who bound it right now.
  - plonk 4y ago
    It took me days to set up my team’s CI/CD pipeline with GitHub’s existing features. If I started from a simple mailing list, it would take months of full-time work to add automated build steps with dependencies between steps, caching, secure secret management, proper authentication, a practical issue database, and link that to my git repo. At that point, I would have a completely new product that takes a full-time maintainer and has the same complexity as the big players. It would be more efficient to fork GitLab. I think you don’t realize how wasteful that is. And what’s the point? There’s already a well-maintained FOSS self-hosted solution that benefits from not being based on antiquated technologies.
    - kkfx 4y ago
      At that point you might have discovered not needing at all 99% of DevOps concepts, and that probably they exists because they help some making profits not because are good ideas. In that terms, it's OT and very long to discuss here, my opinion is that's about time to ERASE 30+ years of IT crappy history to start back at pioneering time Xerox PARC for instance where ALL we use today was invented and implemented far better than now, where their antiquated technologies are actually far more advanced than most we use everyday calling them new and advanced. An OS must came back to a unique fully-integrated environment, with a single programming language, no matter if Lisp, Smalltalk or something else, applications simply do not exists, are just built-in functionality we develop inside the system, deploy is just pushing code to available instances etc. Such VERY ancient model is actually far more advanced than modern one, demand far less efforts and resources giving back far more. It's not there because at a certain point in time IBM decide that compartmentalization and crap made profit and modern IT giants understand that very well going far beyond.
klibertp 4y ago
Oh boy, I was wrong. You were serious? I mean, I myself am often telling other programmers to study history of the field, pointing out that a lot of "ground-breaking" ideas were invented in the '70s, but trying to bring those ideas as realized back then to today's world is not going to work. Both USENET and self-hosted mailing lists died for a reason: it's too cheap to spam them and with increasing number of users, the probability of someone wanting to fuck them up approaches 1. Self-hosting is a good thing, but you can get halfway there by simply having a backup hosting from an unrelated entity. Actually, if you look at GNU Emacs development that I'm familiar with, it's conducted over a mailing list and a self-hosted git repo, but that repo is mirrored and backed up on GitHub...