Engineering director at Canonical Rick Spencer has replied to this story. He says:
Ubuntu is not changing to a rolling release. We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu.This is a wide-ranging project that we will continue to pursue through our normal planning processes.
I have a multi-boot desktop Linux system with a 1.5 TB hard drive, a number of Linux distributions on different partitions (Debian, Gnewsense, Ubuntu), and some virtualized Linux distributions living as KVM'd images that I use on those distributions as well.
Lately, what I have been primarily running has been Ubuntu's Maverick Meerkat's alpha and then beta. Not to suggest the alpha was always rock-solid - sometimes huge bugs crept up in it that had me switching back to my stable Ubuntu Lucid Lynx distribution. But if they were bad they were usually dealt with swiftly.
Here is why I think Ubuntu, Canonical and Maverick Meerkat have done a great job.
In February of this year, I was installing Debian squeeze on another system. Once installed, I looked in/etc/fstab to see information on my disk partitions. The disk information was in UUID format, and a comment line in fstab said "Use 'vol_id --uuid' to print the universally unique identifier for a device". So, I did what the file told me and did a "vol_id --uuid". But it didn't work. There was no vol_id program. I did a little digging and saw that the vol_id program had been a part of the udev package on lenny, but now it no longer was. The program to decode those mysterious UUID's had disappeared. I did a little more digging and discovered the blkid program in the util-linux package could decode those UUIDs. I tried it out, it translated the UUIDs to device names for me, and I was happy. However, I realized/etc/fstab was still giving everyone faulty information. So in February I filed a bug report with Debian.
So now it is October, and my bug report sits in Debian's bug tracker, undisturbed by anyone. There have been four updates to the partman-target package (which creates the initial/etc/fstab) since my bug, but none implementing my suggestion to remove the outdated suggestion of using the no longer existent vol_id program, and replacing it with a suggestion to use blkid. In August, Debian squeeze froze in anticipation of release, so it becomes more unlikely my bug will be fixed.
So where does Ubuntu stand with all of this? Well back in May, Ubuntu resynchronized their partman-target with Debian. While doing so, someone checked out Debian's bug tracker, saw my report, and fixed the problem in Ubuntu. While their change log in May notes this, I can see it myself when looking at/etc/fstab on my meerkat - "Use 'blkid -o value -s UUID' to print the universally unique identifier for a device".
So this - I find impressive. I am having a problem with Debian and report a bug there, although it remains unfixed. But Ubuntu comes in and fixes the bug which was put on the bug tracker of another system.
Yes, this is just talking about the quality of the distribution and not all of the other things involved, which of course, are important. I know how some Debian developers were (and some still are) unhappy with Canonical and Ubuntu, and how some other upstream contributors are unhappy with Canonical (like Linux developer Greg Kroah-Hartman) and so forth. And whatever acrimony exists, I think the Debian folks and Linux folks and the like are right that Canonical and Ubuntu have to find a way to push more patches upstream. Here is a case though where the bug fix was already upstream, but only Ubuntu decided to implement it.
Considering that I got Ubuntu for free (as in beer), I have been very happy with the responsiveness of the (Canonical etc.) Ubuntu team to my problems and patches via their bug-tracking system, Launchpad. As far as I'm concerned, it is one of the best, and probably largest, testbeds of the Gnome desktop environment out there. I think it's really going to allow for a good, integrated Gnome desktop environment experience, and hopefully the Canonical/Gnome relationship goes w
Why do neither Windows nor FreeBSD have any problem whatsoever with my wireless card, but Linux (any distro... went through 5 in the last 6 months) can only list networks and not connect since new (read: broken) Ralink drivers were put into mainstream kernel?
This is the same problem I had - my RAlink card automagically worked on the 10.04 release, but broke on the 10.10 development version. I didn't have time to look into it so I put aside using 10.10 for a few months. A few weeks ago I had some time, so I looked into it and saw that the rt2860sta and rt2800pci modules conflicted, so I blacklisted rt2800pci. This was the biggest problem I encountered, and it is still there.
Other problems? Xpdf stopped working. The English language help menus are full of Unicode gibberish, which has been reported 22 times, and which 13 people say affects them (I actually figured out the fix myself - launchpad bug #605577 - they've yet to patch it, you just have to overwrite a bad yelp.po file with a good one).
Another problem - by default, switching from one workspace to another does this whooshing thing, which after a lot of switching workspaces starts to get annoying (for me at least). Turning these desktop effects off causes problems though - gnome-terminal's crash (launchpad bug #6229753) and windows from all workspaces all suddenly appear in the first workspace (launchpad bug #622582).
Well, various freezes are going into effect with 10.10, so the mucking around is ending and the fixing can really begin. Some of the bugs are harder to fix than others. Hopefully a lot of this will be fixed in the next month. I've been doing what I can, when I have the time.
The way this census was done, more weight seems to be given to a more cathedral way of looking at things (What company officially maintains a module? What commits come from e-mail addresses from that company?) then a bazaar way of doing things (Which company is getting good, automated bug reports from users? Which company has a decentralized, web 2.0 way of dealing with those bugs? What company's OS gets patches written for those bugs, often from its own users, or developers using their OS?)
I don't think Ubuntu got a fair shake compared to Red Hat. I usually use Red Hat in my work environments and Ubuntu and/or Debian at home. One of the packages in the bubble I am familiar with is evince. I look at the bug reports for evince for every distribution - Ubuntu, Debian, Red Hat, whatever. Most of the reports, and most of the good reports, come from Ubuntu. Honestly I think the census is really skewed - to me launchpad is one of the best places to see where regular users are having problems with the Gnome environment. It is where bugs caused by normal (and sometimes abnormal) operations by regular users comes to light the most when using the Gnome operating system, as far as I'm concerned. I always go to Ubuntu's launchpad first, and then check the other distribution's bug pages.
The module in the GNOME diagram I am most familiar with evince. Evince is the default GNOME PDF viewer. Now one problem with faulting the Ubuntu side for not contributing enough code to evince is that evince is fairly lightweight in terms of just itself. Most of the time when evince crashes, or fails to display a page correctly, or has some other error, it is almost never due to evince code, but in the code of libraries evince depends on. Primarily evince depends on the poppler library (a PDF rendering library), and poppler depends on the cairo library (a graphics library). Poppler is used by both GNOME and KDE. If an Ubuntu user complains evince is crashing for them, and a Canonical developer sees this is a poppler problem and sends a patch to poppler, Canonical would not be credited in the census. The way the census was done, this wouldn't count, although it is what Ubuntu does best in improving GNOME. Non-Canonical Ubuntu developers who use Launchpad improve GNOME as well, but this is not counted either in the census.
And what happened to that guy who was thrown in jail for non-fraudently fixing satellite dishes so they could see certain channels?
Oh yaa, that was in the US, forget about it.
Of course Al-Manar is "terrorist"...according to the US, and other current/former British colonies (which I'll call CFBC's). This seems to be a CFBC confusion though, no other countries in the world aside from the CFBC's (and Holland for some reason) see Al-Manar or Hezbollah as terrorist.
For my Computer Science degree, both of those courses were required.
If you are only going to take one, I would recommend discrete math. It is more programmer oriented - algorithms, solving problems with discrete math, doing proofs for equations and so on. This is the stuff that comes up in programming again and again and again.
As far as the other math subject you mention, differential calculus and so on, that also comes up in programming, and it is good thing to know it.
But if one or the other, discrete mathematics is more important to understand in order to do programming.
Money, code and endorsements are some methods of contributing, but there are many ways to help.
This list is good, but it can also be used as a jumping off point. For example "submit bug reports". That is one thing you can do, but there are a lot of bug-related things you can do. Bugs are reported to the wrong place, bugs are reported with little information etc. Someone doing the grunt work dealing with that takes the load off of developers who can be doing higher level work.
Also, I wouldn't sell myself short on coding ability. Say someone files a bug that something that worked for them in version 2.3 is now broken in version 2.9. You can go through the versions and see which was the last working version - this saves the developers time in having to do that. You can even go through each code commit between versions and see which one broke the functionality - this will save developers even more time. You can do a lot of grunt work to narrow down problems for developers without even really understanding how the code works.
Slashdot Mirror
Lately, what I have been primarily running has been Ubuntu's Maverick Meerkat's alpha and then beta. Not to suggest the alpha was always rock-solid - sometimes huge bugs crept up in it that had me switching back to my stable Ubuntu Lucid Lynx distribution. But if they were bad they were usually dealt with swiftly.
Here is why I think Ubuntu, Canonical and Maverick Meerkat have done a great job.
In February of this year, I was installing Debian squeeze on another system. Once installed, I looked in /etc/fstab to see information on my disk partitions. The disk information was in UUID format, and a comment line in fstab said "Use 'vol_id --uuid' to print the universally unique identifier for a device". So, I did what the file told me and did a "vol_id --uuid". But it didn't work. There was no vol_id program. I did a little digging and saw that the vol_id program had been a part of the udev package on lenny, but now it no longer was. The program to decode those mysterious UUID's had disappeared. I did a little more digging and discovered the blkid program in the util-linux package could decode those UUIDs. I tried it out, it translated the UUIDs to device names for me, and I was happy. However, I realized /etc/fstab was still giving everyone faulty information. So in February I filed a bug report with Debian.
So now it is October, and my bug report sits in Debian's bug tracker, undisturbed by anyone. There have been four updates to the partman-target package (which creates the initial /etc/fstab) since my bug, but none implementing my suggestion to remove the outdated suggestion of using the no longer existent vol_id program, and replacing it with a suggestion to use blkid. In August, Debian squeeze froze in anticipation of release, so it becomes more unlikely my bug will be fixed.
So where does Ubuntu stand with all of this? Well back in May, Ubuntu resynchronized their partman-target with Debian. While doing so, someone checked out Debian's bug tracker, saw my report, and fixed the problem in Ubuntu. While their change log in May notes this, I can see it myself when looking at /etc/fstab on my meerkat - "Use 'blkid -o value -s UUID' to print the universally unique identifier for a device".
So this - I find impressive. I am having a problem with Debian and report a bug there, although it remains unfixed. But Ubuntu comes in and fixes the bug which was put on the bug tracker of another system.
Yes, this is just talking about the quality of the distribution and not all of the other things involved, which of course, are important. I know how some Debian developers were (and some still are) unhappy with Canonical and Ubuntu, and how some other upstream contributors are unhappy with Canonical (like Linux developer Greg Kroah-Hartman) and so forth. And whatever acrimony exists, I think the Debian folks and Linux folks and the like are right that Canonical and Ubuntu have to find a way to push more patches upstream. Here is a case though where the bug fix was already upstream, but only Ubuntu decided to implement it.
Considering that I got Ubuntu for free (as in beer), I have been very happy with the responsiveness of the (Canonical etc.) Ubuntu team to my problems and patches via their bug-tracking system, Launchpad. As far as I'm concerned, it is one of the best, and probably largest, testbeds of the Gnome desktop environment out there. I think it's really going to allow for a good, integrated Gnome desktop environment experience, and hopefully the Canonical/Gnome relationship goes w
Why do neither Windows nor FreeBSD have any problem whatsoever with my wireless card, but Linux (any distro... went through 5 in the last 6 months) can only list networks and not connect since new (read: broken) Ralink drivers were put into mainstream kernel?
This is the same problem I had - my RAlink card automagically worked on the 10.04 release, but broke on the 10.10 development version. I didn't have time to look into it so I put aside using 10.10 for a few months. A few weeks ago I had some time, so I looked into it and saw that the rt2860sta and rt2800pci modules conflicted, so I blacklisted rt2800pci. This was the biggest problem I encountered, and it is still there.
Other problems? Xpdf stopped working. The English language help menus are full of Unicode gibberish, which has been reported 22 times, and which 13 people say affects them (I actually figured out the fix myself - launchpad bug #605577 - they've yet to patch it, you just have to overwrite a bad yelp.po file with a good one).
Another problem - by default, switching from one workspace to another does this whooshing thing, which after a lot of switching workspaces starts to get annoying (for me at least). Turning these desktop effects off causes problems though - gnome-terminal's crash (launchpad bug #6229753) and windows from all workspaces all suddenly appear in the first workspace (launchpad bug #622582).
Well, various freezes are going into effect with 10.10, so the mucking around is ending and the fixing can really begin. Some of the bugs are harder to fix than others. Hopefully a lot of this will be fixed in the next month. I've been doing what I can, when I have the time.
I don't think Ubuntu got a fair shake compared to Red Hat. I usually use Red Hat in my work environments and Ubuntu and/or Debian at home. One of the packages in the bubble I am familiar with is evince. I look at the bug reports for evince for every distribution - Ubuntu, Debian, Red Hat, whatever. Most of the reports, and most of the good reports, come from Ubuntu. Honestly I think the census is really skewed - to me launchpad is one of the best places to see where regular users are having problems with the Gnome environment. It is where bugs caused by normal (and sometimes abnormal) operations by regular users comes to light the most when using the Gnome operating system, as far as I'm concerned. I always go to Ubuntu's launchpad first, and then check the other distribution's bug pages.
The module in the GNOME diagram I am most familiar with evince. Evince is the default GNOME PDF viewer. Now one problem with faulting the Ubuntu side for not contributing enough code to evince is that evince is fairly lightweight in terms of just itself. Most of the time when evince crashes, or fails to display a page correctly, or has some other error, it is almost never due to evince code, but in the code of libraries evince depends on. Primarily evince depends on the poppler library (a PDF rendering library), and poppler depends on the cairo library (a graphics library). Poppler is used by both GNOME and KDE. If an Ubuntu user complains evince is crashing for them, and a Canonical developer sees this is a poppler problem and sends a patch to poppler, Canonical would not be credited in the census. The way the census was done, this wouldn't count, although it is what Ubuntu does best in improving GNOME. Non-Canonical Ubuntu developers who use Launchpad improve GNOME as well, but this is not counted either in the census.
And what happened to that guy who was thrown in jail for non-fraudently fixing satellite dishes so they could see certain channels? Oh yaa, that was in the US, forget about it. Of course Al-Manar is "terrorist"...according to the US, and other current/former British colonies (which I'll call CFBC's). This seems to be a CFBC confusion though, no other countries in the world aside from the CFBC's (and Holland for some reason) see Al-Manar or Hezbollah as terrorist.
If you are only going to take one, I would recommend discrete math. It is more programmer oriented - algorithms, solving problems with discrete math, doing proofs for equations and so on. This is the stuff that comes up in programming again and again and again.
As far as the other math subject you mention, differential calculus and so on, that also comes up in programming, and it is good thing to know it.
But if one or the other, discrete mathematics is more important to understand in order to do programming.
This list is good, but it can also be used as a jumping off point. For example "submit bug reports". That is one thing you can do, but there are a lot of bug-related things you can do. Bugs are reported to the wrong place, bugs are reported with little information etc. Someone doing the grunt work dealing with that takes the load off of developers who can be doing higher level work.
Also, I wouldn't sell myself short on coding ability. Say someone files a bug that something that worked for them in version 2.3 is now broken in version 2.9. You can go through the versions and see which was the last working version - this saves the developers time in having to do that. You can even go through each code commit between versions and see which one broke the functionality - this will save developers even more time. You can do a lot of grunt work to narrow down problems for developers without even really understanding how the code works.