That's a really bad idea!
Ubuntu development team has proven in the time not to be able to cope with real development, software integration and bug fixing.
The Ubuntu people have one thing in mind: profit opportunities.
That's not a bad thing, of course. It's bad when it's the only one thing you keep in mind.
A lot of work for marketing, colors, icons, themes and other eye candy.
But, as far as stability and effectiveness, they are far behind.
Most of the time they simply push bugs upstream to either Debian or to the (actual) application developers.
A few examples can help.
Ubuntu desktop doesn't use a desktop-grade kernel. I mean a kernel promoting the responsiveness. Something you'd expect on ... ehm ... desktop edition.
They instead use a server-grade kernel.
Not to talk when they decided to jump on the KDE v4 wagon and leave KDE users with no usable KDE at all.
That was a marketing decision. They didn't even tried the KDE v4 desktop or read the friendly documentation (stating that KDE v4 was not intended for end users).
Finally, when they really get to the solution to some issue, they fix it for the future release, not the current one or the latest LTS.
As if non-techie users were longing to make a complete distribution upgrade every six months. This is not the real use case.
A faster release cycle would simply emphasize this kind of attitude, thus leading to a fast suicide. Bugs would accumulate on older versions, while newer ones would show new bugs. With no time and resources to fix.
Ubuntu has had the merit to really push Linux to non-geek non-hackers desktop. Well they have not been the first ones nor the best ones.
But nowadays when you talk about desktop Linux, Ubuntu is among the two or three names that you can hear.
A suicide here would be a big loss to the Linux community.
Maybe a rolling distribution, already discussed in the past, would instead be a better idea. But also here, again, the quality assurance process should be much more important than eye candy.
So, please Ubuntu devs, don't do monthly release. Thanks.
Ubuntu development team has proven in the time not to be able to cope with real development, software integration and bug fixing.
The Ubuntu people have one thing in mind: profit opportunities.
That's not a bad thing, of course. It's bad when it's the only one thing you keep in mind.
A lot of work for marketing, colors, icons, themes and other eye candy.
But, as far as stability and effectiveness, they are far behind.
Most of the time they simply push bugs upstream to either Debian or to the (actual) application developers.
A few examples can help.
Ubuntu desktop doesn't use a desktop-grade kernel. I mean a kernel promoting the responsiveness. Something you'd expect on ... ehm ... desktop edition.
They instead use a server-grade kernel.
Not to talk when they decided to jump on the KDE v4 wagon and leave KDE users with no usable KDE at all.
That was a marketing decision. They didn't even tried the KDE v4 desktop or read the friendly documentation (stating that KDE v4 was not intended for end users).
Finally, when they really get to the solution to some issue, they fix it for the future release, not the current one or the latest LTS.
As if non-techie users were longing to make a complete distribution upgrade every six months. This is not the real use case.
A faster release cycle would simply emphasize this kind of attitude, thus leading to a fast suicide. Bugs would accumulate on older versions, while newer ones would show new bugs. With no time and resources to fix.
Ubuntu has had the merit to really push Linux to non-geek non-hackers desktop. Well they have not been the first ones nor the best ones.
But nowadays when you talk about desktop Linux, Ubuntu is among the two or three names that you can hear.
A suicide here would be a big loss to the Linux community.
Maybe a rolling distribution, already discussed in the past, would instead be a better idea. But also here, again, the quality assurance process should be much more important than eye candy.
So, please Ubuntu devs, don't do monthly release. Thanks.
Comment