Slashdot Mirror
Torvalds Bemoans Size of RC7 For Linux Kernel 3.5
alphadogg writes "A host of small modifications and a large number of system-on-a-chip and PowerPC fixes inflated the size of release candidate No. 7 for Version 3.5 of the Linux kernel, according to curator Linus Torvalds' RC7 announcement, made on Saturday. Torvalds wasn't happy with the extensive changes, most of which he said he received Friday and Saturday, saying 'not cool, guys' in the announcement. However, the occasionally combustible kernel curator didn't appear to view this as a major setback. 'Now, admittedly, most of this is pretty small. The loadavg calculation fix patch is pretty big, but quite a lot of that is added comments,' he wrote, referring to the subroutine that measures system workload."
Linus is getting bitchy lately.
To offset political mods, replace Flamebait with Insightful.
Linus bitches and moans about the size of every release candidate. Better that broken stuff gets fixed now rather than with an ever-lengthenng string of point releases after the fact.
If I'm reading the article correctly, this isn't so much about file size as about the number of bugs fixed. Or rather, how many bugs still needed fixing in what was supposed to be the seventh release candidate of the kernel: something one would not expect to find so many bugs in very quickly.
Is this the case?
Who the hell this Linus thinks he is by criticizing Linux development??!111?
"Not cool guys." - linus OHMYGHOSH, front page news.
If I were in Linus' shoes working on the same goddamn thing for a couple of decades, I think I would have resorted to fire bombing by now.
I think he should pass the torch to someone else and go do something fun - or just be a devoted dad.
Sounds like the kernel could use a good refactoring.
Because too many people contributed too many patches during a window in the development cycle when not many (or large) patches should be contributed?
Umm... I think you didn't understand what the problem is here. It's a violation of development process protocol that has nothing to do with the quality of the code. Someone trying to submit refactoring patches would have made it much worse, not better. Actually, it wouldn't have been worse, because Linus would just have rejected them at this point in time.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Like every large software project it deserves a rewrite from scratch because it's full of cruft, but nobody will ever find the time to do it.
At least some refactoring and de-crufting is done from time to time if some dev gets pissed off enough. Not something that happens in commercial SW development unless the code is hopelessly broken.
thegodmovie.com - watch it
No.
thegodmovie.com - watch it
Sounds like the kernel could use a good refactoring.
Let's recode the whole thing, and this time, we'll do it RIGHT!
Are we talking about source code size, or the actual binary footprint on any individual supported system?
Neither. He's talking about the size of the diff from the previous release candidate (although it's impossible to tell from TFA).
Sounds like the kernel could use a good refactoring.
Indeed. I would suggest separating the ones and zeros into two separate groups so we can keep track of them better.
When all you have is a hammer, every problem starts to look like a thumb.
Actually, size in decimal.
When all you have is a hammer, every problem starts to look like a thumb.
Nope. He's just bitching about Linux being popular.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
This networkworld.com article gets submitted to /.:
A host of small modifications and a large number of system-on-a-chip and PowerPC fixes inflated the size of release candidate No. 7 for Version 3.5 of the Linux kernel, according to curator Linus Torvalds' RC7 announcement, made on Saturday.
LAST TIME AROUND: Linux kernel 3.4 released
Torvalds wasn't happy with the extensive changes, most of which he said he received Friday and Saturday, saying "not cool, guys" in the announcement. However, the occasionally combustible kernel curator didn't appear to view this as a major setback.
"Now, admittedly, most of this is pretty small. The loadavg calculation fix patch is pretty big, but quite a lot of that is added comments," he wrote, referring to the subroutine that measures system workload.
However, he noted, there were also the assorted changes for SoCs, PowerPC compatibility, USB and audio to be folded in, forcing a comparatively large RC7.
"Ok, so it's still not *huge*, but it's bigger than -rc6 was. I had hoped for less," wrote Torvalds.
He also hopes that it won't be necessary to deploy an eighth release candidate before Version 3.5 of the kernel can be properly rolled out, and urged the community to "go forth and test."
Among the biggest new features expected in Linux 3.5 is enhanced compatibility with the ARM processor family, which are used in a wide array of low-cost computing devices. Several ARM-related fixes are part of 3.5-RC7, according to the official announcement email and changelog.
The H-Online reported earlier today that the final version of Linux 3.5 should be deployed next weekend, if all goes well with RC7.
The h-online.com article the networkworld one is a rehashing of:
Over the weekend, Linus Torvalds reluctantly published a seventh release candidate (RC7) for the 3.5 Linux kernel. In the LKML announcement email, the Linux creator says that he originally thought another RC would not necessarily be required; however, a large number of small pull requests submitted by developers late last week necessitated an additional RC for testing, leading Torvalds to tell the developers, "Not cool, guys. Not cool."
These changes include media fixes, random SOC fixes and PowerPC fixes, as well as patches for the leap second bug that caused Linux systems to freeze because of permanent high CPU loads that resulted in increased power consumption and wasted electricity. "Ok, so it's still not *huge*, but it's bigger than -rc6 was," said Torvalds, adding, "I had hoped for less."
Linus has asked the kernel developers to test the rc7 release to "make sure it's all good", and is hoping that he "won't have to do an -rc8". Barring any major problems over the coming week, Linux3.5 will likely be released next weekend. An overview of the changes made in the 3.5 kernel can be found in TheH's Kernel Log mini-series "Coming in 3.5" which examines the various subsystem developments in the upcoming release.
Review each article and notice what is and what is not a link, and where the links lead.
Very disappointed that the geniuses at "Network World" did not include a link to the original article. For articles like this it's much better to read the source material yourself and come to your own conclusions, without the sensationalism and ad-baiting.
The HURD guys would like a word with you...
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
Like every large software project it deserves a rewrite from scratch because it's full of cruft, but nobody will ever find the time to do it.
At least some refactoring and de-crufting is done from time to time if some dev gets pissed off enough. Not something that happens in commercial SW development unless the code is hopelessly broken.
Every time someone says this they should be forced to sit in the corner and and copy this essay by Joel Spolsky on things you should never do 5000 times and give a copy to each of their friends together with an essay about what they have learned from this punishment.
If only there were a way to use a microkernel to run Linux.... ;-)
In poorly factored code, the scope of a change touches more parts of the code than in well factored code, and that bloats the size of the RC.
Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
They want to ask him to join them?
Egads, there hasn't been a new Powerpc in ages except for a few game consoles and people stuck with legacy IBM big iron. Any reason to continue bloating the kernel with that stuff? Time marches on. Why inconvenience everyone so that a few dozen PS3 users can run Linux? :)
The "Not cool guys." comment sounded like he wasn't thrilled they all dumped lots of fixes all at once. You know, like they were sitting on lots of changes and then, in concert, released everything before a release milestone. I doubt it has anything to do with binary footprints.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
IBM still makes and supports PPC. Before that, it would make sense to drop some of the dead RISC CPU support - such as PA-RISC and Alpha. Indeed, given that even Itanium support has been dropped by all distros except Debian, the only RISC that deserves continued support from Linux are ARM, Sparc, MIPS and OpenRISC.
But honestly, when Linux is installed on something, does it have anything like NEXT's fat binaries? I thought that only the target platform binaries were included. How is the support of other platforms like RISC an issue in the code or binary size of RC7?
No they wouldn't. IMHO the reason HURD has moved so slowly is because they told just about everyone who was interested in helping to fuck off. Linus was a bit more diplomatic even when people without much of a clue want to join in so it went rapidly from a small group to what we see today. Some of those clueless newbies he was not rude to and didn't scare away 15+ years ago are now a very long way from being clueless newbies.
Why would you compile for other platforms when you don't need to? Oh wait, you wouldn't, so those Alpha, Mips, and even VAX binaries that you never see in an x86 distro wouldn't be on your embedded system either unless that's that platform you want. Which raises two questions: are you lying or did somebody feed you that shit which you are passing on with understanding it?
He's 42. That's more than "approaching" middle age. Furthermore, it's the answer.
Contribute to civilization: ari.aynrand.org/donate
In fact the core of the kernel has already been refactored many times and is of excellent quality. It represent only a very small percentage of the whole code. Most of the code is drivers. Many drivers are poorly written and may need to be rewritten, but developers are too busy coding the many missing drivers.
In fact there is no real problem in Linux code, just a recent increase in the number of developers.
In some cases a rewrite is actually wanted and warranted..
- Code is just bad and impossible to understand..
- Code it slow, has become to bloated...
- Hard to debug and hard to track down problems happen from time to time.
You start with a small corner and when that small part is done, and working, then you might go for the next thing... But don't throw out everything.. just the parts that are bad... And while you are doing things like this you should try and do some type of unit-test implementation also to make sure your new code works as the old code was intended to work.
Well, it did have quite a big effect on their ftp... Never got any good speeds back then, especially the days after a new kernel-release..
I don't think so. His "jokes" are all just insults at people that dare to be computer geeks or misleading bullshit that is a million miles away from being funny. It's stuff along that lines where if somebody compiles code for a program they have to be pointed out as a freak to laugh at.
In which "era" do you base your impression?
The real reason HURD has moved so slowly (besides managerial incompetence) is that HURD has ceased to be a product with a deadline. HURD is now an operating system research project, with the goal of tinkering with it long enough to publish a paper on their findings or dilettante OS topic.
HURD was originally designed with the presumption that microkernel architecture would be more desirable (operate more efficiently) than a monolithic kernel (that has been the basis for almost every commercial OS since UNIX). You can't really make a breathtaking, next generation OS if the basis that it operates upon either works like crap, or requires different paradigms to communicate from kernel to OS tasks. The lost decade of the 2000's has been spent finding a "suitable" microkernel replacement to MACH. (Which is decidedly unsuitable, since it was designed in the 1980's, and is better off replaced, than kludged.) You can compound the failure with the fact that it has to conform to GNU's operating charter (translation: there might have been a suitable commercially developed microkernel, but if it didn't license it GNU v2.0 (now v3.0), it was unacceptable. That's okay; I'm only speaking hypothetically about the existence of a suitable microkernel for HURD.)
The most striking irony is that HURD may be the empirical demonstration that microkernel architecture is a research dead end, and there aren't any that can even match monolithic kernel designs. The other irony is that hypervisors, which to me seem to be a form of microkernel, have long outdistanced traditional microkernel efforts, although I couldn't tell you why they would still be unsuitable for HURD (besides the license).
Nevertheless, I was pretty shocked that the "core" developers are still actually documenting their progress. They're actually pasting in snippets of their IRC conversations into the wiki documentation (from days ago!).
So, yeah, there's a reason why the "core" people involved are telling volunteers to fuck off. If you can't speak Microkernel Chinese, they don't even want you generating background noise. I'd say the definition of clueless newbies would be someone from 15+ years ago trying to participate in HURD today.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon