Quotes of the week [LWN.net]

Note, I also removed the line in the unusedcode.easy file at the same time, if I shouldn't have done that, let me know and I'll redo these patches.

If I messed anything up, or the patches need more information within the body of the changelog, please let me know, and I'll be glad to respin them.

-- Greg Kroah-Hartman becomes a LibreOffice developer.

If we really want to improve the world we should jump into a time machine and set tabstops to 4.

-- Andrew Morton

10? We have a few cases of variables over 100 (not sure how you are supposed to use them with an 80 character max line length). Current longest is:

eOpenLogicalChannelAck_reverseLogicalChannelParameters_multiplexParameters_h2250LogicalChannelParameters

at 104 characters.

Tony Luck (see include/linux/netfilter/nf_conntrack_h323_types.h)

With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but no non-GPL file system can make this call.

That means non-GPL file systems cannot exist any more unless they do not use any VFS functionality related to reading/writing as far as I can tell or at least as long as they want to implement direct i/o.

What are commercial file systems meant to do now?

-- Anton Altaparmakov

(Log in to post comments)

Quotes of the week

Posted Feb 9, 2012 17:53 UTC (Thu) by nowster (subscriber, #67) [Link]

This summer... GregKH is... the Tabulator.

Quotes of the week

Posted Feb 9, 2012 17:55 UTC (Thu) by nowster (subscriber, #67) [Link]

That should have been "Andrew Morton". Apologies to both.

tabs

Posted Feb 11, 2012 0:53 UTC (Sat) by giraffedata (subscriber, #1954) [Link]

or maybe just prevent them from being born?

I assume you mean born as features of Linux kernel code (because the world would be a worse place if tabs hadn't existed in the 1960s and 70s).

Were tabs actually obsolete when Linus wrote the first Linux code? Did he (and did he have to) use an editor that couldn't tab over without actually inserting a tab character in the file? Or was his use of tabs just habit?

Quotes of the week

Posted Feb 13, 2012 11:02 UTC (Mon) by etienne (subscriber, #25256) [Link]

I believe having a tab evey eight chars is still a very effective way to reduce the physical size of the kernel source file, one of the first compression system.
Maybe in the future we will have processor with so much layer 1 memory cache (or a way to reload a layer 1 cache line from main memory a gazillon times a second) that we will no more care, but that is not my computer right now.

Quotes of the week

Posted Feb 13, 2012 19:32 UTC (Mon) by nix (subscriber, #2304) [Link]

We don't care anyway. It's *source code*. The tabs or spaces get scrunched out in tokenization, and the stages after that use so very much more memory that the L1 and indeed L2 caches are blown no matter what you do.

Tabs versus spaces might matter for compilation speed if compilers routinely allocated 30K when compiling a program. They don't. They allocate 30Mb or 300Mb, and stamp all over it in a nearly random fashion.

Mental levels of indentation

Posted Feb 13, 2012 22:49 UTC (Mon) by dmarti (subscriber, #11625) [Link]

I thought the whole point of deep tabs was to spare your brain having to figure out over-complicated logic. From Documentation/CodingStyle...

"Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.

In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning."

Quotes of the week

Posted Feb 14, 2012 10:44 UTC (Tue) by etienne (subscriber, #25256) [Link]

> We don't care anyway. It's *source code*

Well, compiling tabs or spaces doesn't matter, but comparing (diff -r) and managing (storing, copying) source tree is different.

Quotes of the week

Posted Feb 14, 2012 11:53 UTC (Tue) by nix (subscriber, #2304) [Link]

If you're hitting the disk to get the source code off it, you have already lost, and the 5%-or-less increase in time needed to handle the occasional run of spaces is going to be lost against the 100000% increase you had because you had to hit the disk in the first place.

Most people diffing and grepping source trees do it to one source tree more than once. The second time, it's in the cache, and that run of spaces doesn't slow it down at all. (Diff and grep algorithms find runs of characters utterly trivial to deal with, unless you're looking for something like " * * a" in which case you deserve to suffer!)