Debian GNU/Linux Keeps Getting Stronger

Look at the steepness of the bug-count for the next release (green curve) at Debian. Even as the count of packages in the repository rises, the rate at which bugs are getting killed in the release-cycle keeps rising. This shows the power of FLOSS. By using a modular layered approach, a thousand people can change the world faster than tens of thousands working in the darkness of M$. It’s beautiful that you can have the benefits of a package manager that keeps all your systems updated for applications as well as the OS at very low cost. I recommend Debian GNU/Linux. It works for you.

At this rate, Debian may well release “Wheezy” (30K+ packages and everything needed to manage them) before “8”:

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

7 Responses to Debian GNU/Linux Keeps Getting Stronger

  1. Dann says:

    Speaking of Debian…

    LLVM’s clang compiler is now capable of building most Debian packages for most architectures.
    Choice is good.

  2. oiaohm says:

    Clarence Moon really go read the link.

    Wine Project is one of the most interesting development cycles. Release every ~2 weeks.

    Scum is close to FOSS model but not exactly.

    There is no daily scrum meeting in FOSS projects this become unworkable when you are global.

    Really the daily scrum is replaced by mailing list that a person can read whenever and post to whenever.

    Planning meeting in foss is normally people mentioning they are taking particular projects to work on to prevent duplication.

    There are differences. Result is less management.

    Key to Foss working well is items like git. That allows developers to fork off there own working tree so test out new features and ideas before integrating back into mainline.

    FOSS is mostly a model of forking and merging. Fork off test something merge back in when it somewhat tested. FOSS is min formal meeting coding.

    Of course people who are use to visual studio try applying scrum to a FOSS project and the Project suffers because of it. Scrum model does not apply to a global operation. Scrum is a flawed design for global development.

    Pity wikipedia does not document generic Agile programming. Open Source project have a lot of models of Agile all related but all slightly different.

  3. Clarence Moon says:

    Meetings, committees, bureaurcracies described as efficient?

    If I had a problem with someone else’s code on a project that I was working on, I would much prefer to walk over to the person’s office and discuss it face to face than to send an email and wait for a reply. Developers can do that at our place.

    Are you familiar with Agile Programming? That is another big thing these days. So much so that it has been immortalized in the Hitler series.

  4. Phenom says:

    Agile. Have you heard about it, or are you stick stuck with Waterfall, which is exactly where heavy bureaurcracy is involved?

    “…Levels of complexity…”
    Lets stick to do DOS 1.0, shall we? Who needs directories in its filesystem anyway, that’s a level of complexity!

  5. Ivan says:

    Did you just call Microsoft a slow and inefficient bureaucracy while hyping Debian, itself a slow and inefficient bureaucracy that only recently started supporting installing 32-bit applications in a 64-bit environment because of their slow and inefficient bureaucracy?

  6. Clarence Moon wrote, of M$’s programmers, are likely to be much more efficient than a rag-tag group of independent souls who converse on an email thread

    Meetings, committees, bureaurcracies described as efficient? Not in my experience. Those meetings are likely where some manager got to tell the programmers slow-everything, malware, layers of complexity, Metro and a bunch of other things were good for them. Most programmers I know want things to work first and foremost and glitz afterwards. Salesmen, of course, get everything backwards and we know they are in charge at M$. Gates retired. Ballmer never wrote a line of code and doesn’t seem to care whether or not anything works as long as he can force OEMs to sell it.

    Which of those committees designed Azure to fail on Leap Day? What about LonghornVista? It certainly was not “on time and under budget”. For that matter, why is “8” taking so long? GNU/Linux takes a couple of weeks to port to any new ARMed gadget… and a distro can be built on it more or less instantly.

  7. Clarence Moon says:

    a thousand people can change the world faster than tens of thousands working in the darkness of M$

    An interesting theory, Mr. Pogson, but you seem to have missed the simple fact that the developers at Microsoft are not working in the dark in terms of not having free and easy access to the source code. For that matter, if you are not aware of it, Microsoft ISVs, even direct competitors, have access to that source under NDA to facilitate their own testing and defect correction.

    It is in everyone’s best interest to have this capability, of course, and Microsoft recognizes this fact. That is why MSDN was created back in the early 1990s, so that ISVs had easy access to whatever they needed to create popular Windows applications.

    My own opinion is that the internal Microsoft developers, who have been organized into teams for addressing specific segments of Windows functions and who are paid handsomely to stay at their posts full time and who meet with one another regularly to discuss progress and problems, are likely to be much more efficient than a rag-tag group of independent souls who converse on an email thread and apply themselves when and if their whim and fancy dictate.

    Now I may be wrong, but that is what I see in the world.

Leave a Reply