In response to another merge request, Andrew Morton retorted, "argh. I have a backlog of maybe 300 patches here which I am cheerfully ignoring while concentrating on preventing 2.6.23 from being less of a disaster than it has already been." He noted that he was not planning to merge any new code into his -mm tree for 2.6.23 inclusion, "the door for new 2.6.23 material shut two weeks ago. Here, at least." He went on to note:
"Please, stop writing patches. Maybe do something to help get 2.6.23 off its back. Like, go review some of the code which people are cheerfully merging five minutes after having written it."
Recent merges into the upcoming 2.6.23 kernel can be found by browsing the gitweb interface to Linus' 2.6 kernel tree. The 2.6.23-rc1 kernel should be released on or shortly after Sunday the 22nd, two weeks after 2.6.22 was released, and at which time the merge window is closed.
From: Andrew Morton [email blocked] To: Rafael J. Wysocki [email blocked] Subject: Re: [PATCH -mm 0/5] Freezer update Date: Wed, 18 Jul 2007 01:03:53 -0700 On Wed, 18 Jul 2007 09:29:30 +0200 "Rafael J. Wysocki" [email blocked] wrote: > The patches in these series update the freezer to eliminate some existing > shortcomings, argh. I have a backlog of maybe 300 patches here which I am cheerfully ignoring while concentrating on preventing 2.6.23 from being less of a disaster than it has already been. Please, stop writing patches. Maybe do something to help get 2.6.23 off its back. Like, go review some of the code which people are cheerfully merging five minutes after having written it. > so please consider them as 2.6.23 material. The door for new 2.6.23 material shut two weeks ago. Here, at least. Later, OK?
Disaster?
Until this 2.6.22, this has worked:
1) wait for 2.6.X release
2) Wait for first patch (2.6.X.1)
3) make menuconfig; make; make modules-install install
This time, I noticed the quality hit. I like to run the bleeding edge stuff, but obviously the process has broken down. I reverted to 2.6.21.
I am not being critical of the kernel. The entire Linux community is disintegrating. We have the old Unix-types who love Redhat so they don't really have to delve into "kernel-level" details, yet the kernel is so simple. They are useless morons. I hope Redhat/Suse pays their salaries until they retire VERY soon! Enjoy the shuffleboard, you can talk about your glory days with 8-bit processors in your rocking chairs! You have contributed NOTHING to Linux or anything else since before 1999!
Then we have new college-student types, who of course think they know everything, even though they were only trained in Java/C#, who will pollute the kernel code. Looking back, just out of university (a LONG time ago), I realize now I didn't know very much at that time.
Then we have a legion of MSCE's that want to learn Linux "quickly", so they can do to Linux what they have done to the MSFT products. Perhaps they can get Ubuntu "partially installed" on some machines. These "people" are not a problem because if you ignore them, they will starve to death before they can create a working Linux system.
Unfortunately, the "community" consists of a lot of soon to be shuffleboard players, and sellouts to MSFT, who tell me "the REAL world requires using MS Office tools ...".
It seems we first have to eliminate some so-called "Friends of Linux" before we can move forward.
You seem to be at war
You seem to be at war
And you belong to which
And you belong to which group...?
...and of course there are
...and of course there are there is a big bunch of arrogant people who seemed to have been around forever, criticizing everyone and everything. Of course you are right, we should eliminate them all! In fact, the kernel code should not be licensed under the GPL, only a few, the chosen, should be allowed to see it.
Maybe the old "unix types"
Maybe the old "unix types" knows that the kernel release rate have simply gone too high to still meet stability... and are not interested in the race to "run the bleeding edge stuff"... more and more buggy as hell: If you want this stuff, help debugging it! Otherwise, you should accept a debian kernel change rate.
But maybe coming back to unstable/stable(X.Y.2N) releases may also help making good kernel bases to feed the geek that doesn't want to get his hands outside his ass.
about your username
Is your username a joke, unfortunate coencidence, or are you the real Steve Ballmer
lol
The OP is one of the most ridiculous and ignorant comments I've ever seen on the web.
steve.ballmer: Please take your nonconstructive misguided attempts at criticism elsewhere. The only thing you accomplished was making it very clear you have no idea what you're talking about.
And then there are the
And then there are the trolls, and those who pay attention to their mindless baiting.
And then there are the recursives, who goad others for paying attention to the aforementioned whilst doing so themselves.
We need to fork the kernel
The process has broken down because of several design/architecture errors:
1) The language 'C' is very poor to code complex things in. C++ can help, but unfortunately what the usual C++ coder creates is also not suitable for the kernel. C++ with a lot of restrictions would help. Yes Linus, we probably cannot use standard C++ library exception handling, that is obvious, why would you even consider that?
2) The attempt to force vendors to reveal hardware interfaces through a goofy, 1960's design kernel where the interfaces keep constantly changing as they make them up. This sounds like GPL idealism, yet Linus has no such idealism, just read his many opinions on GPLv3. If we are going to create a kernel for Microsoft, we don't need it to look like some disaster that could run in MSDOS 32-bit protect mode.
Linus in the past has been able to create a giant mess and with enough helpers, and somehow make it work. I have encountered and fixed a lot of this beginner-level GPL 'C' code, or should I compliment them, it takes a true master to take something that is a mess to start with, add more mess, and somehow end up with a working mess? It certainly makes one want to shoot oneself to try to work on such "code". I know, I have been working on such a project for many months.
You can call me a troll all you want. In the past, this was to control "high volumes/numbers of posts". No Linux board has any such problem currently. Soon to be shuffleboard players now on Linux boards jump on a single "OP" post (in one month!) as excessive "bandwidth". (You actually prove my point, how many years back do you have to go to find where "OP" matters on any Linux board -- certainly pre-1999). Any web server can easily handle the volume of any posts on the subject Linux right now, even something hosted on 386 machine running Windows ME with full virus/spyware could handle the volume of intelligent Linux posts being created currently.
It is my plan to create a race of perfect robotic creatures, called "Daleks", using the new forked kernel. These will be the supreme creatures in the entire universe. You will obey ME, or you will be exterminated!
Lighten up guys, we're all on the same side!