

Linux founder Linus Torvalds delivers a smackdown like no other - shandsaker
http://www.attendly.com/linux-founder-linus-torvalds-delivers-a-smackdown-like-no-other/

======
eridius
Linus is an incredibly egotistical ass. Yes, he's right about a lot of stuff.
But when he's wrong, he cannot possibly even admit to that possibility.

Case in point, #6 there where he slams the HFS+ filesystem. This started an
extremely long flamewar on the Git ML[1], between me and Linus, with everyone
else piling in on the whole "Linus is always right" bandwagon. If you read the
thread, you'll find that I was giving an explanation for why HFS+ stores
filenames the way it does and why it actually makes sense in context, whereas
Linus basically resorted to "it's crap because I say so". More specifically,
he couldn't even admit that there were two approaches that had sensible
arguments (filenames are human-readable strings, which HFS+ uses, vs filenames
are sacred buckets of bits, which Linus believes). Instead, anyone who
disagrees with him is obviously a moron.

[1]: <http://thread.gmane.org/gmane.comp.version-control.git/70688>

~~~
theevocater
One of Linus's main points is that this is a layer problem.

Who cares if things get normalized in your Finder dialogs or other UX
elements? But if something is being programmatically done to the filesystem
itself (ie, by git via a write) it should do what is advertised -- write some
bits. It seems wrong that the filesystem itself should be concerned with
normalizing filenames or flipping bits of any kind.

~~~
eridius
It's not a layer problem. The fundamental problem is Linux is geared towards
servers and HFS+ is geared towards consumers. On a server, it makes sense that
whatever filename your program tries to write out is preserved perfectly. On a
consumer-facing OS that's a terrible idea. Having mis-normalized filenames can
cause all sorts of confusion. The most obvious is having two filenames that
are grapheme-for-grapheme identical, but differ in the normalization of their
characters. Less obvious is how to deal with situations where the user types a
filename to open and their typed normalization differs from the actual
normalization of the file on disk? Unless the filesystem itself performs the
renormalization, there's no sane way to deal with this situation besides
iterating over the directory and renormalizing each filename in the hopes of
finding a match.

~~~
mbell
I don't follow, looking at the number of files on my laptop right now a very,
very small percentage of them are intended for my interaction. The vast
majority are intended purely for interaction by programs / the system. That
tells me the file system should handle what is best for that case and my
interaction should be proxied by another program that makes the file system
fit for my consumption, e.g. Finder.

~~~
eridius
Of all the files on my system, the only ones that even hit the normalization
issue are explicitly meant for human interaction. OS files typically aren't
named using non-ASCII characters.

~~~
mbell
That is exactly why they are a special case that should be handled by the file
manager, not the file system.

~~~
eridius
You seem to be deliberately ignoring the fact that they _cannot_ be handled by
a layer on top of the filesystem without introducing all sorts of weird
behavior and severe inefficiencies.

------
garysb
Without going into to much politics about how Linus handles his responses, how
many random questions a day would you respond nicely to until you just started
writing things like "because I am right!"?

In terms of file systems I believe that both opinions have flaws. Who thought
that giving the user the choice of case sensitivity was a good idea when
creating HFS+? And to take it a step further, why create any kind of
hierarchy? why not just define a "bucket of bits, being content" with a set of
associated meta for an inode that defines structure and naming, that way
everyone can have their cake and eat it. Or am I missing something?

~~~
esolyt
Well, Linux filesytems (ext2, ext3, ext4) are case-sensitive as well.

~~~
Dylan16807
The problem is the choice, not the sensitivity.

~~~
eridius
What's wrong with the choice? The vast majority of people won't even see the
choice (since they're not formatting their drives manually in Disk Utility)
and will get the case-insensitive default that Mac OS has always had. But
there are occasional reasons why one would actually want a case-sensitive HFS+
filesystem and for those people, there's a choice.

------
mahmud
this appears like a hand-crafted linkbait to help their SEO. What does
"Attendly" have to do with this anyway?

------
eridius
medusa666, you appear to be hellbanned. All of your comments for the past 3
weeks are [dead]. I don't see anything obviously spammy in your history,
although a karma of -2 is curious.

~~~
crusso
And the "666" in the user name didn't give away Medusa's intent?

------
petdance
This is not something to be celebrated. It's an embarrassment and it
encourages the same behavior in others.

