Slashdot Mirror
A Visual Expedition Inside the Linux File Systems
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."
I could use a visual expedition among the various links on this summary.
This analysis was done on 1337 kernel modules
This is where we are, our rock we stand, among the world, looking forward, eternally.
What does it all mean?
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.
This analysis was done on 1377 kernel modules from 2.6.0 to 2.6.29
I think they meant 1337 kernel modules?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Nothing. The whole point was do create said visualizations. From the "expedition" homepage here:
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.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Usefulness of a hammer:
XXXXXXXXXXXXXXXXXXXXXXXXX
Usefulness of an average Slashdot article:
XXXXXX
Usefulness of a screen door on a submarine:
XXXX
Usefulness of this Slashdot article:
X
Am I the only one not understanding a word nor the point of those graphics, but still going to print them as posters and put them everywhere in my bedroom ?
'cuz dude, it's so beautiful !
Segmentation Fault in "Life, Universe and Everything" at line 42. Don't Panic.
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!
Dear submitter,
A /. summary is a bit like a main page on a website. Make the organization clear. Don't pile on shortcuts to different parts of the website: the reader risks being discouraged trying to find out how best to get to the important part of your website. Less is better.
I actually clicked on one of the links that appeared to go to the "Expedition" website (based on its similarity to other links, as shown in my browser's statusbar!), then changed the address in the address bar to get to the front page.
You actually didn't include a link to your article's front page, for heaven's sake!
Hope this helps for the next time you write a summary.
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
My first reaction when browsing through the article was disgust about the measure being used. I couldn't see the value of graphs about the number of symbols used by different file-system modules. So vfat doesn't use kprintf, woo-fucking-hoo!
But then, the Hamming distance and hierarchical structure struck a chord. Huh, so NFS, uses a very different set of symbols than, ext3. (ok, this may be biased by NFS using a metric fuckton of external symbols where ext3 uses less), which implies that NFS is pretty different, internally, than ext3.
So now, I agree that such a visualisation, while very abstract from the implementation details, can be pretty useful to have a (very) rough overview of the filesystems and their code structure. And I think we need more abstract overviews like this.
Reminds me of Code Swarm, which creates a movie of commits to a repository.
Misleading titles? Inflammatory blurbs? Keep in mind that Slashdot is a tabloid.
It's easy.
I did it once and the fact that it couldn't be mounted was offset by the fact that no bugs were ever reported, nor did it it ever corrupt or lose any data. In fact, I didn't even have to write any of the implementation.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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 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.