Linux - DistributionsThis forum is for Distribution specific questions.
Red Hat, Slackware, Debian, Novell, LFS, Mandriva, Ubuntu, Fedora - the list goes on and on...
Note: An (*) indicates there is no official participation from that distribution here at LQ.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Ubuntu is very controversial among Linux devs as Canonical backports new code and features into old versions of applications. This causes a crapload of bugs that can be solved by just upgrading the software to the latest versions.
Furthermore, Canonical actually expects developers to portion out the new code and bugfixes for them and expects the original developers to support their half-working backported software for them. This is exacerbated by the fact that Ubuntu contributes very little back to the original code, mostly because they are spending so much time backporting code. A lot of Linux developers are rightly pissed about this.
Backporting code is great for security fixes, but it isn't a solution for every problem under the sun. In Ubuntu's case, it definitely creates more problems than it fixes.
Ubuntu needs a change in direction. I propose that Ubuntu adopt a development model where only the core operating system, userland, core libraries, and desktop environment are frozen every 6 months. The applications would then be freely updated to the newest versions at all time. Package maintenance and support for the end-user applications would be provided by the developers themselves.
This new release system would be very similar to the semi-rolling release system I implemented in infinityOS.
Last edited by ryro22; 05-05-2010 at 05:09 PM.
Reason: Thanks mostlyharmless for the typo
Ubuntu is very controversial among Linux devs as Canonical backports new code and features into old versions of applications.
The majority of successful Linux distributions (Ubuntu, Debian, Fedora, Red Hat, Suse, etc.) follow this development model. Rolling release distros have had every opportunity to capture the market and have failed. I admire your ideology, but Ubuntu's "backport bug fixes to stable applications" development model has rocketed them all the way to number one.
The majority of successful Linux distributions (Ubuntu, Debian, Fedora, Red Hat, Suse, etc.) follow this development model. Rolling release distros have had every opportunity to capture the market and have failed. I admire your ideology, but Ubuntu's "backport bug fixes to stable applications" development model has rocketed them all the way to number one.
It has also led to things like Grub being broken the day before a LTS release.
It's time that Linux grew up. Linux is now a production operating system. We want to play games and for Linux to have a proper audio framework that allows for game development. We also want desktop effects without our videos tearing. It's time we abandon X11 and PulseAudio and write frameworks for Linux that meet the needs of users.
I have serious concerns about the release system employed by Ubuntu and feel that the sound system it uses is inadequate for the needs of the average user (it can stream music to your kitchen but can't play games...).
The proposals I posted on the Ubuntu developer mailing lists were rejected so I will be taking infinityOS in a different direction than Ubuntu. infinityOS will remain 100% binary compatible with Ubuntu. My goal is for infinityOS to become the Firefox to Ubuntu's Mozilla.
I've received a lot skepticism that my approach will introduce instability. We will be keeping the core OS and core packages the same as Ubuntu's so we will be able to take advantage of their security updates. For end-user applications, the up-to-date releases provided by PPAs would be more than enough. infinityOS is not intended to be used on a server.
I don't see how upgrading Firefox, MPlayer, and Wine (among other end-user applications) to the latest versions will have an effect on stability. Most people I know who use Ubuntu on a daily basis have a list of around 15 PPAs they use to keep their software up-to-date. infinityOS will automate this process and add a bit of needed testing to the packages in the PPAs.
We will be using a yearly core OS release schedule, instead of the semi-annual release schedule employed by Ubuntu. This means that infinityOS will be binary compatibile with with every 2nd Ubuntu release (including every LTS release). The yearly release schedule will start with Lucid, as we will be skipping Maverick due to concerns about the effect the introduction of Gnome 3.0 will have on stability.
-----
I will be working to decentralize the maintenance and control of infinityOS a bit in the next week. I'm looking to move my PPAs/repositories over to a trusted team, with about 3 people having the ability to push and upload packages.
I want the development of infinityOS to mirror that of the development of the Linux kernel. E-mail me (or a member of the core team) a notification of your package update, and I (or a member of the core team) will push it to either the "testing" or "unstable" repos, depending on the libraries it depends on and the stability of the code reflected in our testing. If it is pushed to "testing" and no major problems appear in a week, it will be pushed to "stable" and all infinityOS users will be notified of the update.
You would probably have received a better reception (here) if you had included the input in post #8 in your initial post. My initial reaction was "WTF - why wasn't this moaned about on canonicals list(s)".
Personally I've found the last few (er, several) Ubuntu releases flaky as hell at general release. I tend to install a week or two before the next GA - mostly stable by then. Not my primary distro though.
I now have a core dev team of 3 people. The other two have quite a bit of experience with Linux as well. Only the core dev team will be able to push updates (and only I will be pushing updates to "stable"). Interestingly, they are both 10 years older than me. I wanted people who I could trust but could also call me out on my screwups.
Now this I firmly agree with. IMHO PulseAudio is one of the most ridiculous cases of overengineering ever. It does a load of fancy things that hardly anyone needs. Audio is basically simple and should not be made overcomplicated.
It doesn't cover application updates, only *new* applications. It seems also a bit process and red-tape heavy ATM, but that stuff can be moderated later on.
It's a step forward to say the least, but I'm disappointed that it doesn't cover application updates.
-----
I think leaving maintenance of the end-user applications to the developers will free up a ton of resources so the Ubuntu developers can focus on making the core OS stable. In addition, it also removes the major reason for having a new version of Ubuntu every 6 months. This will give the developers of Ubuntu more time to test the OS.
Basically, I feel that having the applications updated and distributed separately from the core OS releases will result in a more stable distribution.
-----
I wrote a response to the mailing post I linked above, detailing my criticisms of the proposed application review process.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.