How it shall look… # Linux & BSDs # Windows # macOS # State on Fedora 40 Workstation & XFCE Spin… # Screenshots taken from the GNOME bugtracker, copies to not stall their GitLab instance.
That is a misconception that 99% of the devs don’t understand. Sometimes you do need major changes that break stuff to upgrade the base. GNOME started doing it recently. Keeping old bases for a very long time makes them bloated, hacky, slow and unstable
In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.
That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.
GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.
Linus Torvalds is author and maintainer of one of the most successful pieces of software ever written ( software that is decades old and still growing in popularity ).
What does Linus says about your philosophy that “Sometimes you do need major changes that break stuff to upgrade the base”? I think his first sentence explains where he stands but he expands on his initial point.
Implementing old standards does not magically result in unstable software. I can create software today that implements decades old standards using whatever whiz-bang tech is in vogue.
I do lot accept that “old bases” have to succumb to any of the things you suggest either. Refactoring is a thing. You can remove dead code, you can adopt new patterns, you make code modular, you can even extend using new tech if you want.
Linux is 30 years old ( the basic design is decades older ). Should we throw it out? I vote no but allowing Rust into the kernel seems like a good idea. How old is GCC? How old is Microsoft Office? How old is Firefox? This is software you may use every day. Trust me, your life relies on software that is much, much older. How often do you think they rewrite air traffic control systems or core financial software to to make it more “stable” as you suggest?
I mostly hear your argument when devs want to try new tech and cannot justify it any other way. Most often the result is something that is far buggier and missing many features. By the time the features return, the new code is at least as bloated as the original. Around then, somebody usually suggests a total rewrite.
Old architectures are a different story. Sometimes things are not worth fixing in place. In my experience though, this is fairly rare. Even then, in-place migration to something else often makes more sense.
In my view, if you cannot modernize an old code base, it is a skills issue.
That is a misconception that 99% of the devs don’t understand. Sometimes you do need major changes that break stuff to upgrade the base. GNOME started doing it recently. Keeping old bases for a very long time makes them bloated, hacky, slow and unstable
In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.
That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.
GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.
I won’t even try to explain. People here only want to argue
No, you’re just dense.
I imagine most readers will assume that response indicates that you have no argument.
That is totally fine. I doubt anybody wants to fight. I am glad we were able establish the value you had to add.
If you don’t want to argue (which I highly appreciate) it doesn’t mean others don’t too. This place is quite toxic
deleted by creator
Linus Torvalds is author and maintainer of one of the most successful pieces of software ever written ( software that is decades old and still growing in popularity ).
What does Linus says about your philosophy that “Sometimes you do need major changes that break stuff to upgrade the base”? I think his first sentence explains where he stands but he expands on his initial point.
https://lkml.org/lkml/2012/12/23/75
Something Stomething. NEVER BREAK USER SPACE!
Implementing old standards does not magically result in unstable software. I can create software today that implements decades old standards using whatever whiz-bang tech is in vogue.
I do lot accept that “old bases” have to succumb to any of the things you suggest either. Refactoring is a thing. You can remove dead code, you can adopt new patterns, you make code modular, you can even extend using new tech if you want.
Linux is 30 years old ( the basic design is decades older ). Should we throw it out? I vote no but allowing Rust into the kernel seems like a good idea. How old is GCC? How old is Microsoft Office? How old is Firefox? This is software you may use every day. Trust me, your life relies on software that is much, much older. How often do you think they rewrite air traffic control systems or core financial software to to make it more “stable” as you suggest?
I mostly hear your argument when devs want to try new tech and cannot justify it any other way. Most often the result is something that is far buggier and missing many features. By the time the features return, the new code is at least as bloated as the original. Around then, somebody usually suggests a total rewrite.
Old architectures are a different story. Sometimes things are not worth fixing in place. In my experience though, this is fairly rare. Even then, in-place migration to something else often makes more sense.
In my view, if you cannot modernize an old code base, it is a skills issue.