Thoughts on the ext4 panic
The timeline
On October 23, user "Nix" was trying to help track down an NFS lock manager crash when he ran into a little problem: the crash kept corrupting his filesystem, making the debugging task rather more difficult than it would otherwise have been. He reported the problem to the linux-kernel mailing list; he also posted a warning for other LWN readers. The ext4 developers moved quickly to find the problem, coming up with a hypothesis within a few hours of the initial report. Unfortunately, the hypothesis turned out to be wrong.
Before that became clear, though, a number of news outlets had posted articles on the problem. LWN was not the first to do so ("first" is not at the top of our list of priorities), but, late on the 24th, we, too, posted an item about the issue. It quickly became clear, though, that the original hypothesis did not hold water, and that further investigation was in order. That investigation, as it turns out, took a few days to play out.
Eric Sandeen eventually tracked the problem down to this commit which found its way into the mainline during the 3.4 merge window. That change was meant to be a cleanup, gathering the inode allocation logic into a single function and removing some duplicated code. The unintended result was to cause the inode bitmap to be modified outside of a transaction, introducing unchecksummed data into the journal. If the system crashed during that time, the next mount would encounter checksum errors and refuse to play back the journal; the filesystem was then seen as being corrupt.
The interesting thing is that, on most systems, this problem will never come about because, on those systems, the journal checksums do not actually exist. Journal checksumming is an optional feature, not enabled by default, and, evidently, not widely used. Nix had turned on the feature somewhat inadvertently; most other users do not turn it on at all, even if they are aware it exists. Anybody who has journal checksums turned off will not be affected by this bug, so very few ext4 users needed to be concerned about potential data corruption.
As an interesting aside, checksums on the journal are a somewhat problematic feature; as seen in this discussion from 2008, it is not at all clear what the best response should be when journal checksums fail to match. The journal checksum may not be information that the system can reasonably act upon; indeed, as in this case, it may create problems of its own.
Eric's patch appears to fix the problem; corrupted journals that were easily observed before its application do not happen afterward. There will naturally be a period of review and testing before this change is merged into the mainline — nobody wants to create a new problem through undue haste — but kernel releases with a version of the fix (it has already been revised once) should be available to users in short order. But most users will not really care, since they were not affected by the problem in the first place. They may care more about the plans to improve the filesystem test suites so that regressions of this nature can be more easily caught in the future.
Analysis
In retrospect, the media coverage of this bug was clearly out of proportion to that bug's impact. One might attribute that to a desire for sensational stories to drive traffic, and that may well be part of what was going on. But there are a couple of other factors that are worth keeping in mind before jumping to that judgment:
- Many media outlets employ editors and writers who, almost beyond
belief, are not trained in kernel programming. That makes it very
hard for them to understand what is really going on behind a
linux-kernel discussion even if they read that discussion rather than
basing a story on a single message received in a tip. They will see a
subject like "Apparent serious progressive ext4 data corruption,"
along with messages from prominent developers seemingly confirming the
problem, and that is what they have to go with. It is hard to blame
them for seeing a major story in this thread.
- Even those who understand linux-kernel discussions (LWN, in its arrogance, places itself in this category) can be faced with an urgent choice. If there were a data corruption bug in recent kernels, then we would be beyond remiss to fail to warn our readers, many of whom run the kernels in question. There comes a point where, in the absence of better information, there is no alternative to putting something out there.
The ext4 developers certainly cannot be faulted for the way this story went. They did what conscientious developers do: they dropped everything to focus on what appeared to be a serious regression affecting their users. They might have avoided some of the splash by taking the discussion private and not saying anything until they were certain of having found the real problem, but that is not the way our community works. It is hard to imagine that pushing development discussions out of the public view is going to make things better in the long run.
Thus, one might conclude that we are simply going to see an occasional episode like this, where a bug report takes on a life of its own and is widely distributed before its impact is truly understood. Early reports of software problems, arguably, should be treated like early software: potentially interesting, but likely to be in need of serious review and debugging. That's simply the world we live in.
A more serious concern may apply to the addition of features to the ext4 filesystem. Ext4 is viewed as the stable, production filesystem in the Linux kernel, the one we're supposed to use while waiting for Btrfs to mature. One might well question the addition of new features to this filesystem, especially features that prove to be rarely used or that don't necessarily play well with existing features. And, sure enough, Linux filesystem developers have raised just this kind of worry in the past. In the end, though, the evolution of ext4 is subject to the same forces as the rest of the kernel; it will go in the directions that its developers drive it. There is interest in enhancing ext4, so new features will find their way in.
Before getting too worried about this prospect, though, it is worth
thinking about the history of ext4. This filesystem is heavily used with
all kinds of workloads; any problems lurking within will certainly emerge
to bite somebody. But problems that have affected real users have been
exceedingly rare and, even in this case, the number of affected users
appears to be countable without running out of fingers. Ext4, in other
words, has a long and impressive record of stability, and its developers
are determined to keep it that way; this bug can be viewed as the sort of
exception that proves the rule. One should never underestimate the value
of good backups, but, with ext4, the chances of having to actually use
those backups remain quite small.
Exceptions and rules
Posted Oct 29, 2012 14:52 UTC (Mon)
by rfunk (subscriber, #4054)
[Link] (21 responses)
Posted Oct 29, 2012 14:52 UTC (Mon) by rfunk (subscriber, #4054) [Link] (21 responses)
Exceptions and rules
Posted Oct 29, 2012 14:57 UTC (Mon)
by corbet (editor, #1)
[Link] (2 responses)
We have an internal reviewer who will be gratified by your comment.. sorry to have marred your experience. I'll make a rule not to use that phrase again, with only rare exceptions.
Posted Oct 29, 2012 14:57 UTC (Mon) by corbet (editor, #1) [Link] (2 responses)
Exceptions and rules
Posted Oct 29, 2012 16:53 UTC (Mon)
by Trelane (subscriber, #56877)
[Link]
Posted Oct 29, 2012 16:53 UTC (Mon) by Trelane (subscriber, #56877) [Link]
I cannot take exception to that exceptional rule.
Exceptions and rules
Posted Oct 30, 2012 11:40 UTC (Tue)
by zack (subscriber, #7062)
[Link]
Posted Oct 30, 2012 11:40 UTC (Tue) by zack (subscriber, #7062) [Link]
Chapeau.
Exceptions and rules
Posted Oct 29, 2012 15:33 UTC (Mon)
by nix (subscriber, #2304)
[Link] (6 responses)
Posted Oct 29, 2012 15:33 UTC (Mon) by nix (subscriber, #2304) [Link] (6 responses)
Exceptions and rules
Posted Oct 29, 2012 15:40 UTC (Mon)
by rfunk (subscriber, #4054)
[Link] (5 responses)
Posted Oct 29, 2012 15:40 UTC (Mon) by rfunk (subscriber, #4054) [Link] (5 responses)
Exceptions and rules
Posted Oct 29, 2012 16:29 UTC (Mon)
by khim (subscriber, #9252)
[Link] (3 responses)
Posted Oct 29, 2012 16:29 UTC (Mon) by khim (subscriber, #9252) [Link] (3 responses)
If there is an actual exception, then the rule fails the test. If the rule passes the test, there's no exception.
Yup. 1001th wrong interpretation of the phrase. If you'll stop complaining for the minute and actually read the meaning of phrase in question you'll find out that original principle is exceptio probat regulam in casibus non exceptis ("the exception confirms the rule in cases not excepted") and that this article used phrase correctly
The very fact that this tiny quirk which needed non-default (and non-recommended) mount options warranted such a huge ruckus means that the rule is ext4 is rock-solid in accordance to the exceptio probat regulam in casibus non exceptis principle.
Exceptions and rules
Posted Oct 29, 2012 16:38 UTC (Mon)
by rfunk (subscriber, #4054)
[Link] (2 responses)
Posted Oct 29, 2012 16:38 UTC (Mon) by rfunk (subscriber, #4054) [Link] (2 responses)
Exceptions and rules
Posted Oct 29, 2012 16:49 UTC (Mon)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Oct 29, 2012 16:49 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)
I was responding to nix's interpretation above. You're correct about the original meaning, of course. But I disagree that the usage here fits the original meaning.
It does. We had a rule: ext4 is rock-solid and is robust no matter what you throw on it (unless you are doing something totally insane like using broken RAID controller). Now we have an exception: if you use ext4 with non-default mount option journal_checksum then you may expect data corruption in some rare cases. The fact that such a small exception raised such a ruckus can be used as a support for the original rule (after all if the file system corrupts data all the time then yet-another-bug in it will hardly be a newsworthy material).
Even if I accept that it does, however, just the fact the the phrase is widely misunderstood and misused should consign it to the dustbin; if most people don't understand it correctly, communication isn't happening.
Most people on this planet don't understand English. Should we stop using it and close LWN?
Exceptions and rules
Posted Oct 29, 2012 18:40 UTC (Mon)
by randomguy3 (subscriber, #71063)
[Link]
See Wikipedia's article on the phrase, which enumerates 5 usages (from most correct to least correct) from Fowler's Modern English Usage. I think that the article's usage would fit in number 3 (loose rhetorical): the use of the phrase is to draw attention to the fact that something is uncommon. The existence of the bug does not imply that bugs are uncommon. Nor is the ruckus itself an exception from anything.
Posted Oct 29, 2012 18:40 UTC (Mon) by randomguy3 (subscriber, #71063) [Link]
Most people on this planet don't understand English. Should we stop using it and close LWN?"Most people on the planet" is irrelevant. "Most people who read LWN" is much more relevant, and "tech-savvy English speakers" is a good approximation of that.
Exceptions and rules
Posted Oct 29, 2012 16:29 UTC (Mon)
by epa (subscriber, #39769)
[Link]
I think the idea is that the apparent exception to the rule, on closer examination, turns out not to be an exception after all. So the rule still holds. It is silly, though; as you say, if the rule holds then there was no exception after all.
Posted Oct 29, 2012 16:29 UTC (Mon) by epa (subscriber, #39769) [Link]
Exceptions and rules
Posted Oct 29, 2012 15:37 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (8 responses)
Posted Oct 29, 2012 15:37 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (8 responses)
Or, to look at it another way, perhaps it's the usage mavens who are wrong. We don't all have to be Humpty Dumpty, but if the vast majority of people choose to use a word, a phrase or even an entire language in a way that overturns precedent you eventually have to bend to their will or be broken by it. This isn't an example like misnegation where you can argue that perhaps someone didn't mean what they wrote, the author intended exactly these words, they just didn't intend it to mean quite what it once did.
Even eggcorns, which begin with a mistaken re-analysis of a spoken word or phrase, sometimes enter the mainstream. Once upon a time "upmost" was clearly sometimes a mistake for "utmost" today it's unclear, in another century there may be usage mavens insisting "upmost" should be preferred as more logical and "down the pipe" might likewise displace "down the pike".
Exceptions and rules (digression)
Posted Oct 29, 2012 15:55 UTC (Mon)
by Richard_J_Neill (subscriber, #23093)
[Link] (2 responses)
Posted Oct 29, 2012 15:55 UTC (Mon) by Richard_J_Neill (subscriber, #23093) [Link] (2 responses)
Also, "80% proof whisky" means "tested, contains 40% ethanol".
Exceptions and rules (digression)
Posted Oct 29, 2012 19:54 UTC (Mon)
by davidstrauss (guest, #85867)
[Link] (1 responses)
Posted Oct 29, 2012 19:54 UTC (Mon) by davidstrauss (guest, #85867) [Link] (1 responses)
Exceptions and rules (digression)
Posted Oct 29, 2012 23:10 UTC (Mon)
by barryascott (subscriber, #80640)
[Link]
Posted Oct 29, 2012 23:10 UTC (Mon) by barryascott (subscriber, #80640) [Link]
http://en.wikipedia.org/wiki/Alcohol_proof
Exceptions and rules
Posted Oct 29, 2012 15:56 UTC (Mon)
by rfunk (subscriber, #4054)
[Link] (4 responses)
Posted Oct 29, 2012 15:56 UTC (Mon) by rfunk (subscriber, #4054) [Link] (4 responses)
Exceptions and rules
Posted Oct 29, 2012 16:34 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
Posted Oct 29, 2012 16:34 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)
"It's like the Somme out there"
"How does it resemble the Somme?"
"I mean it's incredibly muddy"
"But I am in fact willing to believe that it is muddy"
The legal origin of this idea of an "exception that proves the rule" is fascinating, but the phrase has taken on a life of its own. You will notice that people are also content to say "third time is a charm" (there is no logical reason to believe that third attempts are special in any way) and "If a job's worth doing it's worth doing well" (likewise, a shoddy job may be the only economic or practical option) and many other phrases which can't be defended logically. They're not doing it wrong, these phrases aren't intended to be truthful statements about the world, any more than anybody thought exceptions /actually/ prove a rule.
Exceptions and rules
Posted Oct 29, 2012 16:42 UTC (Mon)
by rfunk (subscriber, #4054)
[Link]
Posted Oct 29, 2012 16:42 UTC (Mon) by rfunk (subscriber, #4054) [Link]
Exceptions and rules
Posted Oct 29, 2012 16:41 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Posted Oct 29, 2012 16:41 UTC (Mon) by khim (subscriber, #9252) [Link]
"Exception that proves the rule" is part of the phrase. The full legal principle is exceptio probat regulam in casibus non exceptis ("the exception confirms the rule in cases not excepted") as you, I hope, know.
Classic example will be Special leave is given for men to be out of barracks tonight till 11.00 p.m.; "The exception proves the rule" means that this special leave implies a rule requiring men, except when an exception is made, to be in earlier. The value of this in interpreting statutes is plain.
Modern example will be Now we know that exceptional case of ext4 with journal_checksum is not stable. Application of exceptio probat regulam in casibus non exceptis principle will mean that: ext4 is stable unless non-standard option journal_checksum is used - and this is indeed the case.
IOW: this article is rare case where phrase "exception that proves the rule" is used correctly.
P.S. When you start badmouthing people and explain that the net is full of explanation about the original meaning of this phrase, and why almost every modern use of it is wrong it's good idea to refresh your own knowledge and see if you understand what the phrase means and when it's appropriately used.
Exceptions and rules
Posted Nov 8, 2012 12:01 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Posted Nov 8, 2012 12:01 UTC (Thu) by Wol (subscriber, #4433) [Link]
Hence, the saying no longer means what it did, because the meaning of the words have changed underneath it.
Cheers,
Wol
Exceptions and rules
Posted Oct 30, 2012 20:01 UTC (Tue)
by cmccabe (guest, #60281)
[Link] (1 responses)
Posted Oct 30, 2012 20:01 UTC (Tue) by cmccabe (guest, #60281) [Link] (1 responses)
Exceptions and rules
Posted Oct 31, 2012 0:43 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Oct 31, 2012 0:43 UTC (Wed) by nix (subscriber, #2304) [Link]
Thoughts on the ext4 panic
Posted Oct 29, 2012 15:43 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Oct 29, 2012 15:43 UTC (Mon) by nix (subscriber, #2304) [Link]
introducing unchecksummed data into the journalMore serious than being unchecksummed, this was a modification made outside all journal transactions. That's... not supposed to happen.
it is not at all clear what the best response should be when journal checksums fail to matchIt is clear that the current response is far suboptimal, but the right approach (aborting only those blocks with corrupted checksums) isn't implemented, and since it relates only to an obscure feature that basically nobody turns on, implementing it hasn't been considered terribly important.
it has already been revised onceTwice. Eric complexified the patch, then Ted simplified it again.
the media coverage of this bug was clearly out of proportion to that bug's impactIn other news, a degree of wind expected on the US east coast today. :)[...]
Many media outlets employ editors and writers who, almost beyond belief, are not trained in kernel programming.
the addition of features to the ext4 filesystem... surely doesn't apply here. This feature has been around for years and years, about as long as ext4 itself. Even this bug caused no more than the loss of a few log entries and half a dozen emails. fsck cleaned up the mess remarkably well, well enough that I thought nothing of smashing the corruption hammer into the same filesystem over and over again while helping characterize the bug.
Quote of the week goes to jcorbet
Posted Oct 29, 2012 17:08 UTC (Mon)
by dskoll (subscriber, #1630)
[Link]
Posted Oct 29, 2012 17:08 UTC (Mon) by dskoll (subscriber, #1630) [Link]
Many media outlets employ editors and writers who, almost beyond belief, are not trained in kernel programming.
Jon, that was priceless.
Thoughts on the ext4 panic
Posted Oct 29, 2012 17:29 UTC (Mon)
by cesarb (subscriber, #6266)
[Link] (6 responses)
Posted Oct 29, 2012 17:29 UTC (Mon) by cesarb (subscriber, #6266) [Link] (6 responses)
"One should never underestimate the value of good backups, but, with ext4, the chances of having to actually use those backups _because of ext4_ remain quite small."
Fixed. As far as I know, ext4 does nothing to reduce the need for backups (unlike some other filesystems with things like built-in mirroring to separate disks or even separate machines).
Thoughts on the ext4 panic
Posted Nov 8, 2012 6:00 UTC (Thu)
by kevinm (guest, #69913)
[Link] (5 responses)
Posted Nov 8, 2012 6:00 UTC (Thu) by kevinm (guest, #69913) [Link] (5 responses)
In the case of application- or user- level corruption, mirroring will simply replicate the error very efficiently.
Thoughts on the ext4 panic
Posted Nov 8, 2012 7:49 UTC (Thu)
by dlang (guest, #313)
[Link]
Posted Nov 8, 2012 7:49 UTC (Thu) by dlang (guest, #313) [Link]
and to _really_ trash things requires automation :-)
automated replication (including mirroring) is a wonderful way to propagate corruption (as someone who has automated the trashing of several hundred systems with a single command, I can really attest to this one)
Thoughts on the ext4 panic
Posted Nov 8, 2012 15:34 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Nov 8, 2012 15:34 UTC (Thu) by nix (subscriber, #2304) [Link]
Thoughts on the ext4 panic
Posted Nov 11, 2012 2:16 UTC (Sun)
by steffen780 (guest, #68142)
[Link] (2 responses)
Posted Nov 11, 2012 2:16 UTC (Sun) by steffen780 (guest, #68142) [Link] (2 responses)
Thoughts on the ext4 panic
Posted Nov 12, 2012 3:58 UTC (Mon)
by kevinm (guest, #69913)
[Link] (1 responses)
Posted Nov 12, 2012 3:58 UTC (Mon) by kevinm (guest, #69913) [Link] (1 responses)
Thoughts on the ext4 panic
Posted Nov 12, 2012 5:10 UTC (Mon)
by neilbrown (subscriber, #359)
[Link]
Posted Nov 12, 2012 5:10 UTC (Mon) by neilbrown (subscriber, #359) [Link]
Linguistic bug threatens linux users!!!!!
Posted Oct 29, 2012 20:36 UTC (Mon)
by bkw1a (subscriber, #4101)
[Link] (2 responses)
Posted Oct 29, 2012 20:36 UTC (Mon) by bkw1a (subscriber, #4101) [Link] (2 responses)
"A nasty language error in a recent Linux Weekly News article has been proven capable of causing a massive cascade of user comments. The error slipped by previously-respected LWN editor Jonathan Corbet. What does an error of this magnitude say about the process of Linux article development?"
Next up: FRANKENSTORM !!!!!
Linguistic bug threatens linux users!!!!!
Posted Oct 29, 2012 22:25 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Oct 29, 2012 22:25 UTC (Mon) by nix (subscriber, #2304) [Link]
(Sorry, just channelling Phoronix forum users for a moment.)
Linguistic bug threatens linux users!!!!!
Posted Oct 30, 2012 12:47 UTC (Tue)
by man_ls (guest, #15091)
[Link]
Posted Oct 30, 2012 12:47 UTC (Tue) by man_ls (guest, #15091) [Link]
What does an error of this magnitude say about the process of Linux article development?Don't worry, Corbet is just the exception that proves the rule.
Thoughts on the ext4 panic
Posted Oct 29, 2012 21:27 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (44 responses)
Posted Oct 29, 2012 21:27 UTC (Mon) by bronson (subscriber, #4806) [Link] (44 responses)
Thoughts on the ext4 panic
Posted Oct 29, 2012 22:36 UTC (Mon)
by nix (subscriber, #2304)
[Link] (42 responses)
Posted Oct 29, 2012 22:36 UTC (Mon) by nix (subscriber, #2304) [Link] (42 responses)
As an aside, this function provides a fairly strong argument against one of eight-character tab indentation and/or wrapping at 80 characters... the lines are so squashed and short that it's really terribly hard to read. Personally I'm more in favour of a '70 character lines, disregarding indentation' rule, which prevents lines becoming too long to be readable without constraining indentation depth hugely: in do_one_pass(), the effective line length due to one while loop plus a switch statement plus a loop or conditional inside one of the cases is about thirty characters, which is just ridiculous. (As for pandering to the tiny minority of people still writing code on VT102s, they can go and get some hardware built sometime in the last twenty years. Punched cards are obsolete: so are 80-character terminals, IMNSHO.)
Thoughts on the ext4 panic
Posted Oct 30, 2012 0:55 UTC (Tue)
by ikm (guest, #493)
[Link] (19 responses)
Posted Oct 30, 2012 0:55 UTC (Tue) by ikm (guest, #493) [Link] (19 responses)
Thoughts on the ext4 panic
Posted Oct 30, 2012 4:28 UTC (Tue)
by martinfick (subscriber, #4455)
[Link] (11 responses)
Posted Oct 30, 2012 4:28 UTC (Tue) by martinfick (subscriber, #4455) [Link] (11 responses)
Thoughts on the ext4 panic
Posted Oct 30, 2012 7:14 UTC (Tue)
by Aliasundercover (subscriber, #69009)
[Link] (9 responses)
Posted Oct 30, 2012 7:14 UTC (Tue) by Aliasundercover (subscriber, #69009) [Link] (9 responses)
I don't see a Linux IDE which allows this. Visual Studio on Windows does, I just have to tell it to work in its multiple document mode.
If given the choice between a pack of x-terms and vi straight out of the 80s and a modern IDE with all the bells and whistles but just one source window I would take x-terms and vi. Hard to imagine how anyone can use these IDEs much less design them the way they are.
Thoughts on the ext4 panic
Posted Oct 30, 2012 12:42 UTC (Tue)
by fb (guest, #53265)
[Link] (4 responses)
Posted Oct 30, 2012 12:42 UTC (Tue) by fb (guest, #53265) [Link] (4 responses)
> I don't see a Linux IDE which allows this.
FYI, just checked and Eclipse (at least Juno/4.2) allows this. I can drag a source tab and place it next to my main source view.
Thoughts on the ext4 panic
Posted Oct 30, 2012 17:26 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Oct 30, 2012 17:26 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)
Thoughts on the ext4 panic
Posted Oct 30, 2012 21:17 UTC (Tue)
by khc (guest, #45209)
[Link] (1 responses)
Posted Oct 30, 2012 21:17 UTC (Tue) by khc (guest, #45209) [Link] (1 responses)
Thoughts on the ext4 panic
Posted Oct 31, 2012 8:40 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Oct 31, 2012 8:40 UTC (Wed) by marcH (subscriber, #57642) [Link]
No it's not easy; you are not supposed to do that. Instead, you are supposed to install and use whatever plug-ins give you the functionality you need *within* Eclipse.
Eclipse is the new Emacs: a Developer Operating System :-)
http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.ecl...
Thoughts on the ext4 panic
Posted Nov 1, 2012 3:52 UTC (Thu)
by Aliasundercover (subscriber, #69009)
[Link]
Posted Nov 1, 2012 3:52 UTC (Thu) by Aliasundercover (subscriber, #69009) [Link]
Hmm, I last poked at Eclipse a while back and got stuck in tile land till I gave up and moved on to try other IDEs which also left me in tiles. I find tiles most unsatisfying as I wind up spending my time fiddling with them and scrolling too small window fragments even on the biggest screen. I much prefer overlapping windows I can customize. I have been working in Kate which lets me arrange things as I like, permits multiple windows into the same source file and shares the screen well with windows from other programs.
Taking another look based on your message I got the Eclipse 3.7 Ubuntu offered me and found I can indeed get decent looking windows if I fiddle enough. It will take time to know if the fiddling stays excessive or I can tame it with more knowledge.
Of course it wants to mangle my code as I type. It really wants me to follow someone's idea of correct style and I know I will be some time getting it to stop helping me by making an awful mess of my code. Why exactly does it insist on extra * characters on each line? (No, don't answer that, I just want to turn it off.)
/*
* I can really do without these fool *s.
* Much preference fussing and still I get *s.
*/
Will have to see. Looking better than last time. Qt Creator and KDevelop never got me this far, not past tiles and tabs with them. So much IDE stuff filling the screen, so little space for the source code I actually care about.
Thanks
Thoughts on the ext4 panic
Posted Oct 31, 2012 9:25 UTC (Wed)
by cesarb (subscriber, #6266)
[Link] (2 responses)
Posted Oct 31, 2012 9:25 UTC (Wed) by cesarb (subscriber, #6266) [Link] (2 responses)
VIM has split/vsplit. Qt Creator also has split modes. And as others have already noted, Eclipse also has something of the sort. IIRC, Emacs can split the screen too.
Thoughts on the ext4 panic
Posted Oct 31, 2012 13:20 UTC (Wed)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Oct 31, 2012 13:20 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)
Emacs 24 can split the screen, both manually and automatically, in so many ludicrous ways I have not begun to explore the possibilities. (The window-management code was rewritten by Martin Rudalics, and the new code is... very flexible. Almost too flexible to understand.)
Thoughts on the ext4 panic
Posted Nov 1, 2012 9:32 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Nov 1, 2012 9:32 UTC (Thu) by ncm (guest, #165) [Link]
1. Wrong
Any others?
Thoughts on the ext4 panic
Posted Nov 1, 2012 19:50 UTC (Thu)
by daglwn (guest, #65432)
[Link]
Posted Nov 1, 2012 19:50 UTC (Thu) by daglwn (guest, #65432) [Link]
Emacs/CEDET.
Thoughts on the ext4 panic
Posted Oct 30, 2012 10:38 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Oct 30, 2012 10:38 UTC (Tue) by nix (subscriber, #2304) [Link]
Thoughts on the ext4 panic
Posted Oct 30, 2012 5:00 UTC (Tue)
by wblew (subscriber, #39088)
[Link]
Posted Oct 30, 2012 5:00 UTC (Tue) by wblew (subscriber, #39088) [Link]
I truly enjoy programming my 1920x1200 27" monitor.
Thoughts on the ext4 panic
Posted Oct 30, 2012 5:01 UTC (Tue)
by MTecknology (subscriber, #57596)
[Link] (1 responses)
Posted Oct 30, 2012 5:01 UTC (Tue) by MTecknology (subscriber, #57596) [Link] (1 responses)
Thanks nix! I love that summary. It saves me from having to read anything or do any of my own research and still sound smart when I explain it to others! :D
Thoughts on the ext4 panic
Posted Oct 30, 2012 10:39 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Oct 30, 2012 10:39 UTC (Tue) by nix (subscriber, #2304) [Link]
But that width is the length of the line from its first character to its last: you do not sweep your eye over the indentation, so it should not count.
Thoughts on the ext4 panic
Posted Oct 30, 2012 18:53 UTC (Tue)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
Posted Oct 30, 2012 18:53 UTC (Tue) by vonbrand (subscriber, #4458) [Link] (3 responses)
According to Poynton's "Ten Common Mistakes in the Typesetting of Technical Documents", a 66-character line of text is widely considered ideal for readability. I've seen other claims in the same vein (e.g. in the LaTeX memoir and KOMA packages documentation, aimed at serious book-writing). The 80 characters come from the IBM punched cards of yore, but their design in turn surely wasn't completely random either.
The decree from the $POWERS_THAT_BE is enshrined in the Linux coding style; trying to change that is futile (or at least, there are more fruitful outlets for your creative energies).
Thoughts on the ext4 panic
Posted Oct 30, 2012 21:00 UTC (Tue)
by dlang (guest, #313)
[Link] (2 responses)
Posted Oct 30, 2012 21:00 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)
When teletypes were built, they used the same print mechanisms and so had the same limits.
When terminals were built, they mimicked the printed stuff (so that you could see everything that you could see on the paper, and it was a waste to have anything wider, since the people who were still using paper wouldn't be able to see it)
IBM punch cards were 80 columns to match the paper as well.
The problem is none of these are good reasons any longer.
As for the ideal column width to read, go do some research on why newspapers use such narrow columns, the ideal width for reading is surprisingly narrow, and NOT 66 characters.
a paperback book is about the outer edge of what a good width is (no matter what the font size)
Thoughts on the ext4 panic
Posted Nov 4, 2012 23:37 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Posted Nov 4, 2012 23:37 UTC (Sun) by marcH (subscriber, #57642) [Link]
Source code and newspaper articles are quite different types of "literature". The are typically laid out in extremely different ways. It would be a very surprising coincidence if their "ideal widths" were the same.
Thoughts on the ext4 panic
Posted Nov 6, 2012 18:25 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Posted Nov 6, 2012 18:25 UTC (Tue) by anselm (subscriber, #2796) [Link]
Newspapers even go to the trouble of having special fonts designed for them (where do you think Times Roman got its name?) in order to be able to cram more type into a narrow column, thus making the effective column width greater.
Thoughts on the ext4 panic
Posted Oct 30, 2012 9:54 UTC (Tue)
by niner (subscriber, #26151)
[Link] (3 responses)
Posted Oct 30, 2012 9:54 UTC (Tue) by niner (subscriber, #26151) [Link] (3 responses)
To quote CodingStyle: "The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."
do_one_pass() is 390 lines long making it very hard to see it's structure anyway which just strengthens the indication of needed refactoring.
Thoughts on the ext4 panic
Posted Oct 30, 2012 10:43 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 30, 2012 10:43 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)
Sorry, I'm as much a fan of functional decomposition as the next man -- actually I go a bit nuts about it -- but the key to that is splitting functions at logical boundaries. Splitting at random because the indentation passes some arbitrary 'too deep' level, when you would not have split it otherwise, is ridiculous -- and this function indicates that the kernel developers do not in fact do this ridiculous thing. (Obviously there *is* an effective length/complexity limit, and perhaps do_one_pass() is past it -- but a hypothetical function with a long stretch of low indentation with a bit of high indentation in the middle of it is *not* made any clearer by splitting the high indentation into a completely arbitrary separate function!)
Thoughts on the ext4 panic
Posted Oct 30, 2012 11:00 UTC (Tue)
by niner (subscriber, #26151)
[Link]
Posted Oct 30, 2012 11:00 UTC (Tue) by niner (subscriber, #26151) [Link]
Maybe I was a bit unclear on this: if there is indeed not a single logical boundary in the function, then well, tough luck. Then this is one of the rare cases where there's just no good solution. Even with an increased character limit, the function would not be that much more readable. It would still be too long to get a good grasp of the structure quickly.
I did not mean that arbitrarily cutting up the function would be a solution, just that usually it is very much possible to decompose and achieve increased readability. That's why I used the word "indication" in my last sentence.
Thoughts on the ext4 panic
Posted Oct 30, 2012 14:14 UTC (Tue)
by viro (subscriber, #7872)
[Link]
Posted Oct 30, 2012 14:14 UTC (Tue) by viro (subscriber, #7872) [Link]
tagp = pointer; // fairly fat expression, actually
while (tagp - pointer <= size) { // again, and so's 'size'
tag = (journal_block_tag_t *) tagp;
flags = be32_to_cpu(tag->t_flags);
/* couple of lines */
err = jread(&obh, journal, io_block);
if (err) {
success = err;
printk(....);
} else {
/* about 50 lines */
}
skip_write:
tagp += sizeof(journal_block_tag_t);
if (!(flags & JFS_FLAG_SAME_UUID))
tagp += 16;
if (flags & JFS_FLAG_LAST_TAG)
break;
}
In a case. Wrapped in a while. Only at Dibbler's, and that's cutting me own throat...
Seriously, in this case 80-column heuristic has worked nicely - the code structure is badly obfuscated and 4-character tabs would only hide a visible indicator of trouble.
Eight character tabs
Posted Oct 30, 2012 13:01 UTC (Tue)
by man_ls (guest, #15091)
[Link] (17 responses)
The 80-char wrapping is obsolete, but the 8-char tab rule is just... puzzling. I usually have 4-char tabs and it works fine. I have used 2-char tabs and they work fine most of the time -- and that was for Python where indentation can get a bit hairy without {} blocks to guide the eye. The kernel coding style implies that 8-char tabs are easier to the eye, but that is a bit subjective -- for me they are much harder to read.
Posted Oct 30, 2012 13:01 UTC (Tue) by man_ls (guest, #15091) [Link] (17 responses)
Is there any real reason why you cannot display tabs as 4 characters locally in your Linux code? After all Linux does use the tab character. I realize that you risk being burnt alive at the stake in some Linux conference if you forget to change tab length and they spot you, but that is a small price to pay for being able to read code comfortably.
Eight character tabs
Posted Oct 30, 2012 14:32 UTC (Tue)
by nix (subscriber, #2304)
[Link] (16 responses)
Posted Oct 30, 2012 14:32 UTC (Tue) by nix (subscriber, #2304) [Link] (16 responses)
Eight character tabs
Posted Oct 30, 2012 14:41 UTC (Tue)
by paulj (subscriber, #341)
[Link] (15 responses)
Posted Oct 30, 2012 14:41 UTC (Tue) by paulj (subscriber, #341) [Link] (15 responses)
Eight character tabs
Posted Oct 30, 2012 17:26 UTC (Tue)
by nix (subscriber, #2304)
[Link] (11 responses)
Posted Oct 30, 2012 17:26 UTC (Tue) by nix (subscriber, #2304) [Link] (11 responses)
Eight character tabs
Posted Oct 30, 2012 21:49 UTC (Tue)
by man_ls (guest, #15091)
[Link] (4 responses)
The problem with spaces is exactly that you cannot change indentation on the fly just by changing the local configuration. Every developer can choose the tabstop that suits them better. It is even possible to have different configurations for different situations: one for the laptop screen, another when the laptop is hooked to a monitor, etcetera. Spaces don't allow that.
Posted Oct 30, 2012 21:49 UTC (Tue) by man_ls (guest, #15091) [Link] (4 responses)
Also, it takes longer to press space four times (or eight) than tab once. You can usually configure your favorite editor to insert the spaces when tab is pressed, even to delete them (:set expandtab in vim), so this issue is not so important.
As to the failure case you mention above, it makes sense to indent always using tabs, consistently. I have now remembered my painful days of aligning arguments using spaces -- it is just not worth it. I prefer to use short argument lists and set line wrap at 120 so I don't ever see multi-line argument lists; if they arise then just indent into a new line.
Eight character tabs
Posted Oct 31, 2012 0:42 UTC (Wed)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Oct 31, 2012 0:42 UTC (Wed) by nix (subscriber, #2304) [Link] (3 responses)
I have never worked on a codebase where changing indentation via tab width changes did anything but turn the codebase into goo. It is hopeless.
The way to reindent is via automatic reindentation programs (such as GNU indent). Teach that your indentation style, and you're home free. Nothing else works.
Eight character tabs
Posted Oct 31, 2012 1:05 UTC (Wed)
by bronson (subscriber, #4806)
[Link] (2 responses)
Posted Oct 31, 2012 1:05 UTC (Wed) by bronson (subscriber, #4806) [Link] (2 responses)
I'm at the point where I'm ready to declare that, on a real world codebase with multiple teammembers, nothing at all works. Nobody likes the whitespace gestapo.
Eight character tabs
Posted Oct 31, 2012 8:52 UTC (Wed)
by man_ls (guest, #15091)
[Link]
You can try telling git to ignore whitespace.
Posted Oct 31, 2012 8:52 UTC (Wed) by man_ls (guest, #15091) [Link]
My point of view is a bit different: tabs are good, therefore avoid everything that doesn't work with tabs. Lining things up is evil, hard wrap-up limits are evil, and so on. Yes, it requires a lot of discipline, but then so does software development in general.
Eight character tabs
Posted Oct 31, 2012 13:17 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Oct 31, 2012 13:17 UTC (Wed) by nix (subscriber, #2304) [Link]
Eight character tabs
Posted Oct 31, 2012 11:40 UTC (Wed)
by etienne (guest, #25256)
[Link] (5 responses)
Posted Oct 31, 2012 11:40 UTC (Wed) by etienne (guest, #25256) [Link] (5 responses)
Well, have you ever used an editor with variable width font?
Why - maybe because text is easier to read...
Then, you can only use tabs to align stuff - unless that is the beginning of the line. If you comment a line using "//" at its beginning stuff stay aligned.
I do not want a hard limit on the number of chars, because not all chars are the same width...
Also, in some case (long debug printf() line), breaking the long line makes the structure of the function more complex than it really is; just tell you editor not to wrap and just ignore the end of the printf() line - it is just a printf()!
Eight character tabs
Posted Oct 31, 2012 13:21 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Oct 31, 2012 13:21 UTC (Wed) by nix (subscriber, #2304) [Link]
Eight character tabs
Posted Oct 31, 2012 17:08 UTC (Wed)
by tialaramex (subscriber, #21167)
[Link]
Posted Oct 31, 2012 17:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
No, thanks all the same but I'd rather actually see the code I'm maintaining and not trust that the bits I can't see aren't important.
I like the ASCII control characters, but most of them don't belong in my source code and that includes U+0009 TAB. Use soft tabs, set the continuous integration software to barf on hard tabs in source code, along with mysterious trailing whitespace and similar sins.
Eight character tabs
Posted Oct 31, 2012 18:52 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Oct 31, 2012 18:52 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)
Eight character tabs
Posted Nov 1, 2012 9:41 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Nov 1, 2012 9:41 UTC (Thu) by ncm (guest, #165) [Link]
Eight character tabs
Posted Nov 1, 2012 12:06 UTC (Thu)
by etienne (guest, #25256)
[Link]
Posted Nov 1, 2012 12:06 UTC (Thu) by etienne (guest, #25256) [Link]
Having 3/4 lines of code with no algorithm meaning does not help to see the structure of the code and is difficult to comment/uncomment at once; it is easier to tell your editor not to wrap lines and so not display the end of those (probably commented) lines.
Obviously you can write the functions print_mystruct_and_cpt(), print_mystruct_and_idx(), ... that you call only once in a commented out block.
Linux source do not have much "logging" lines, so it is not a real problem there.
Eight character tabs
Posted Oct 30, 2012 18:11 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Oct 30, 2012 18:11 UTC (Tue) by marcH (subscriber, #57642) [Link] (2 responses)
Tab indentation was invented to illustrate "The perfect is the enemy of the good".
Let everyone have his own indentation taste from the same source? Great idea on paper. Falls apart on a regular basis. Because it's not compatible with lining up across lines, because it's not compatible with a max width, etc. And because people are only human and will not be disciplined enough.
Eight character tabs
Posted Oct 31, 2012 11:37 UTC (Wed)
by Jonno (subscriber, #49613)
[Link] (1 responses)
Posted Oct 31, 2012 11:37 UTC (Wed) by Jonno (subscriber, #49613) [Link] (1 responses)
Eight character tabs
Posted Oct 31, 2012 18:09 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Oct 31, 2012 18:09 UTC (Wed) by marcH (subscriber, #57642) [Link]
Thoughts on the ext4 panic
Posted Oct 30, 2012 5:33 UTC (Tue)
by shentino (guest, #76459)
[Link]
Posted Oct 30, 2012 5:33 UTC (Tue) by shentino (guest, #76459) [Link]
Plenty of bugs are caused by one patch exposing a defect in another patch.
Thoughts on the ext4 panic
Posted Oct 30, 2012 9:14 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Oct 30, 2012 9:14 UTC (Tue) by marcH (subscriber, #57642) [Link] (1 responses)
... which reminds us one of the ways Apple achieves higher Quality, while most others still fail: no optional features.
(another, related way is: bloat control)
Thoughts on the ext4 panic
Posted Oct 30, 2012 15:10 UTC (Tue)
by salimma (subscriber, #34460)
[Link]
Posted Oct 30, 2012 15:10 UTC (Tue) by salimma (subscriber, #34460) [Link]
But these are just exceptions that prove the rule... *ducks for cover*