4 ms·

> "instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which wil

> "instead of fixing what it has and being standards compliant, it chooses to break away and do its own thing along with the new bugs and other issues which will surely arise." Well, people are still free to maintain and improve those older tools and bring them up to par with newer standards, if they want to. Others would argue it's time to start phasing out code and so-called "standards" we've had since the early 90s in spirit of refactoring various elements in the ecosystem. As with most such efforts - lots of code will be thrown away, some of it will be re-used and re-purposed. I'd argue that in the long run - it's probably a necessary intervention.

Karunamon 8y ago
They don't need to change the frontend to change the backend. There's a certain cognitive load to having to re-learn basic commands, and a certain annoyance when those changes are of little benefit to my day-to-day sysadmin duties.
felixgallo 8y ago
"others" would be right, but the present team doing the refactoring is actively, aggressively incompetent, doesn't listen to even constructive feedback, closes critical bugs with snarky comments, refuses outside contributions, claim outside contributions are literally impossible, and absorbs independent functionality in the name of empire building. So the notional idea of 'refactoring' being better -- yes! But with the constraint being that the people doing the refactoring have to be at least as wise, tasteful, mature, sensible, and thoughtful as the people who came before.
- xtrapolate 8y ago
  Do I have to state the obvious? This is an open source effort. Not all attempts at persuasion bear fruit. If you feel you are being ignored (by what would appear is a group of maintainers you absolutely despise), I guess the other option would be to fork the repo. This would not be the first time in history people split code over disagreements.
  - felixgallo 8y ago
    Unfortunately, Red Hat have politically suborned all of the major distributions, and have rapidly and effectively created dependencies between their solution and other codebases in a transparent effort to create and maintain lock-in and to build barriers against the 'fork' strategy.
cookiecaper 8y ago
As in everything else important, there is a balance to be stricken between stagnation and upheaval. When choosing platforms, how communities weigh this balance is a very important consideration. You want to associate with people and groups who value essentially the "reasonable breeze" mode that keeps life flowing through extant systems. "Natural disasters" may sometimes be justified to help clear out the way-too-old (e.g. systemd or SMF), but they should be rare; systems can only tolerate major disruptions like that once or twice a decade. Linux has an "anything goes" approach, which is usually more symptomatic of the age/maturity of the crowd it draws in than a reasoned decision about where to fall on this balance. That's not necessarily bad, but it makes more of an experimental atmosphere than something reliable, trusted, and stable.

Karunamon 8y ago

They don't need to change the frontend to change the backend. There's a certain cognitive load to having to re-learn basic commands, and a certain annoyance when those changes are of little benefit to my day-to-day sysadmin duties.

felixgallo 8y ago

"others" would be right, but the present team doing the refactoring is actively, aggressively incompetent, doesn't listen to even constructive feedback, closes critical bugs with snarky comments, refuses outside contributions, claim outside contributions are literally impossible, and absorbs independent functionality in the name of empire building. So the notional idea of 'refactoring' being better -- yes! But with the constraint being that the people doing the refactoring have to be at least as wise, tasteful, mature, sensible, and thoughtful as the people who came before.

xtrapolate 8y ago
Do I have to state the obvious? This is an open source effort. Not all attempts at persuasion bear fruit. If you feel you are being ignored (by what would appear is a group of maintainers you absolutely despise), I guess the other option would be to fork the repo. This would not be the first time in history people split code over disagreements.
- felixgallo 8y ago
  Unfortunately, Red Hat have politically suborned all of the major distributions, and have rapidly and effectively created dependencies between their solution and other codebases in a transparent effort to create and maintain lock-in and to build barriers against the 'fork' strategy.

cookiecaper 8y ago

As in everything else important, there is a balance to be stricken between stagnation and upheaval. When choosing platforms, how communities weigh this balance is a very important consideration. You want to associate with people and groups who value essentially the "reasonable breeze" mode that keeps life flowing through extant systems. "Natural disasters" may sometimes be justified to help clear out the way-too-old (e.g. systemd or SMF), but they should be rare; systems can only tolerate major disruptions like that once or twice a decade. Linux has an "anything goes" approach, which is usually more symptomatic of the age/maturity of the crowd it draws in than a reasoned decision about where to fall on this balance. That's not necessarily bad, but it makes more of an experimental atmosphere than something reliable, trusted, and stable.