Tom Horsley writes:
On Sat, 23 Dec 2017 10:50:44 -0500 Sam Varshavchik wrote: > Maybe, perhaps, this approach should've made sense to do so only when NM> actually was able to support all the functionality it was taking over? How's> that for a crazy idea? Does anyone think I'm being completely off-base and > unreasonable, expecting to things to continue to work, as is, by default? Welcome to the world of fedora! Fedora is supposed to be cutting edge, but it is too bad that often turns out to be broken edge instead :-).
To me "cutting edge" means "new stuff that may or may not work". It doesn't mean "stuff that randomly breaks existing stuff that works". I think there's a lot of ground in between. It's not a nuanced distinction.
Let's draw an analogy with something else. Accelerated graphics. Folks who were around that era remember quite well how the things progressed, with the X RENDER extension, and such.
It was an entirely new X infrastructure. There were plenty of growing pains. Certain hardware worked. Then it broke, then it worked again. This went on for a while.
But throughout the evolution of accelerated graphics infrastructure, the traditional unaccelerated X worked flawlessly. You knew you could always, at least, turn off acceleration and have a working, functional desktop. You would no longer get to play with all the new toys, accelerated graphics and video, but you, at least, always go back to the way things were before. It never broke. And it still works just fine. Existing stuff just
did not break.
It did seem to take about 10 years or so for all the features of the old network service to at least supposedly be supported in nm, I'd get a new fedora and say "Ah! Maybe nm works in this release", try it for a while, then go back to network (it is a blessing that they didn't eradicate network as happens all to often with new shiny features).
And see, that's the other thing. How about just making "all the features of the old network service" continue to putter along, in some fashion, while NM works on building its own new shiny ball? If NM is going to be the default, either make it a default for new installs and not upgrades; or make it fully support the existing functionality. That's all.
I originally had a lot of other things that I wrote down, but I just deleted it. It's just screaming into the air. Instead, I'll just sign off by presenting a small puzzle to solve.
Let's take two packages in Fedora: ncurses and pcre. Tons of stuff depends on them. dnf won't let me remove pcre, because dnf itself depends on it. And I was shocked to see that dnf won't let me remove ncurses either because sudo depends on it. Who knew. Despite the dominance of GUI desktops, you still have fundamental dependencies on plain old curses. I have no idea how much stuff really depends on these two. Must be a lot. Using rpm just to test the first level of dependencies, I count 37 for pcre. Just 3 for curses, but that's just first order dependencies.
I never, ever, read the same kind of bitching, the same kind of complaints about ncurses and pcre breaking existing functionality, all the time. It occured to me this week that there is a very obvious and fundamental reason why that is so, and it has absolutely nothing to do with any technical factor, or complexity. It's more simple, and fundamental than that. And that's my puzzle.
I'll just leave a small clue. Both of them have one general attribute in common, that's not present in NM, and pretty much every other package that's constantly bitched about. Figuring out what it is, will explain a lot. I'll just add a postscriptum that this is not an exclusive-or condition. Plenty of stuff has a solid reputation for stability, without having this particular aspect to it; but stuff that constantly triggers a non-stop source of complaints – with few exceptions you can always say one thing about it, as a whole.
Attachment:
pgpILwLZ4x7Gb.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
