A Visual Expedition Inside the Linux File Systems 85
RazvanM writes "This is an attempt to visualize the relationships among the Linux File Systems through the lens of the external symbols their kernel modules use. We took an initial look a few months back but this time the scope is much broader. This analysis was done on 1377 kernel modules from 2.6.0 to 2.6.29, but there is also a small dip into the BSD world. The most thorough analysis was done on Daniel Phillips's tree, which contains the latest two disk-based file systems for Linux: tux3 and btrfs. The main techniques used to establish relationships among file systems are hierarchical clustering and phylogenetic trees. Also presented are a set of rankings based on various properties related to the evolution of the external symbols from one release to another, and complete timelines of the kernel releases for Linux, FreeBSD, NetBSD, and OpenBSD. In all there are 78 figures and 10 animations."
Verry Pretty ...but (Score:5, Insightful)
Is having a large number of external symbols good because it has more integration points or bad because of bloat? I don't think I have ever RTFA and come away with so little understanding before.
Re:Verry Pretty ...but (Score:3, Insightful)
Re:So what? (Score:5, Insightful)
Nothing. The whole point was do create said visualizations. From the "expedition" homepage here [jhu.edu]:
This is an exercise in visualization and kernel exploration. I'm not an expert in either of them but I like file systems and I also find great pleasure in creating visual representations of the things around me. --RazvanME
He likes file systems and he likes to create visual representation of things. There's your explanation. I suspect the guy is a student with too much free time and a desire to be featured on Slashdot.
Eye-candy knowledge (Score:4, Insightful)
'cuz dude, it's so beautiful !
Re:So what? (Score:5, Insightful)
Which is fair enough (unless you happen to have had a quick look at the summary, an even quicker look at the diagrams and thought "d'uh WTF?" to yourself). I think if he'd created a colourful fractal image, or moving dots swirling around then everyone would be saying how great it was. As it is, it looks like dull statistics.
I found the interesting bits to be how closely tux3 kept coming up next to fat or ntfs, whilst btrfs was close to xfs, and ext4 with ext3 and ext2. Maybe there's something in the analysis after all!
After perusing the article, and ... (Score:3, Insightful)
.
.
.
.
.
.
.
.
. Who gives a shit ?
Re:Hmm (Score:2, Insightful)
No kidding. Sometimes I like to (gasp!) RTFA, but in this case I couldn't find out which of the F links went to the F article.
Informative timelines (Score:4, Insightful)
My only interests in filesystems are how much free space I have and whether mine will recover from a power outage. Thus 95% of these graphs are a total bore to me.
But I do like the Timelines [jhu.edu] of kernel releases. Some kernels see an exponential slowdown of release rate as they approach finalization and others are released like clockwork throughout their lifetime.
I'd love to see these methods applied to other topics I care more about, like games and science
When I develop maps for Starcraft, I usually go with a "release when it's ready" approach. That leads to a first public release long after my internal rough draft. Then there are a few quick releases as major bugs are found. And later the releases slow to a trickle as the focus move from bug fixes to balance tweaks. The magnitude of the changes also decreases over time, but each one's effect on game play can be disproportionately large.
But recently I went with a public balancing approach. I released the rough draft to get a feel for how it played. Then released new drafts as often as twice a day as suggestions were made and problems became apparent. I love to see that contrast visually or see other patterns I hadn't considered.
Re:Hmm (Score:3, Insightful)