
Linus Torvalds Answers Your Questions - tmhedberg
http://meta.slashdot.org/story/12/10/11/0030249/linus-torvalds-answers-your-questions
======
mmariani

      Linus on git:
      ...it wasn't all that pleasant to use for outsiders early 
      on, and it can still be very strange if you come from some 
      traditional SCM, but it really has made my life *so* much 
      better...
    

So, here he pretty much acknowledges you have to think like Linus to get git
like Linus. I remember getting bashed here on HN for saying so, but I don't
care and I'll say it again.

From the user's perspective git is not fun to use, at least not like hg or
fossil are. Good programs just get the job done, but great programs are fun to
use.

~~~
ramblerman
You seem to be mixing "unpleasant to use _early on_ " with git as it is
_today_ in order to prove your point.

And to be fair your point is entirely opinion based anyways. You don't like
git (fair enough), but you might be getting bashed because it is a lot of
people's tool of choice.

Personally I absolutely love Git.

~~~
calpaterson
I didn't use git early on, but it's pretty unpleasant to use today as well.
It's fine if you learn the right incantations but it breaks almost every unix
rule in the book. Literally:

<http://www.catb.org/esr/writings/taoup/html/ch01s06.html>

There's only a few guidelines there that git obeys. The most obvious one it
obeys is "separation".

~~~
qznc
Reading through the list of unix rules you linked, I find git reasonably obeys
them.

For example "Clarity is better than cleverness": Git provides a clear internal
structure (Blob DAG). It does not try to provide clever merge algorithms,
since "Buying a small increase in performance with a large increase in the
complexity and obscurity of your technique is a bad trade".

Or another example "Design programs to be connected with other programs". In
contrast to Mercurial, many git commands are separate programs and it is
trivial to implement your own in any language.

Arguably git violates "In interface design, always do the least surprising
thing", since it does not try to provide a comfy start for svn exiles.

~~~
nine_k
For SVN exiles, there-s git-svn
<http://www.kernel.org/pub/software/scm/git/docs/git-svn.html>

------
DigitalJack
I'm not a software developer by trade, but I do tinker. I've thought I
understood pointers fine, but maybe I don't. Can someone who does expand on
Linus' comment regarding deleting an entry from a singly linked list?

I understood the example he lamented, and probably would have done exactly
that. I didn't understand his pointer to a pointer example though.

~~~
ramLlama
When you start the list traversal, you would have something like

    
    
        Node** link = list_head
    

and as you traverse, you would do

    
    
        link = &(entry->next)
    

Then, when you find the entry that you want to delete, link points to either
(a) list_head if you are deleting the first entry or (b) the next pointer of
the previous entry. Either way, doing

    
    
        *link = entry->next
    

does the trick.

This way, you save on the conditional branch.

~~~
fr0sty
That traversal doesn't traverse. It just skip list to entry->next and would
keep resetting.

You could do something like this instead:

    
    
      link = &((*link)->next);

~~~
nickkthequick
Yes and then to set it would be

    
    
      *link = (*link)->next;

------
dkarl
His statements about instruction sets are interesting: basically that people
get excited about low-level instructions that exploit details of processor
architecture, but what would really improve performance are high-level
instructions that allow software to defer to optimal implementations provided
by the processor. Makes sense. Very little software can know the details of
the processor architecture on which it will run, JITed code being a major
exception.

~~~
jlgreco
To what extent does something like the JRE JIT code know about processor
specific details?

You download a single x86 or x86_64 java binary from Oracle; I guess they
could bake in processor specific optimizations for as many processors as they
can think of at the time but I think even then the benefits of high level
instructions that Linus lays out would be present. At the very least it would
simplify what has to happen when a new processor comes out.

~~~
dkarl
_To what extent does something like the JRE JIT code know about processor
specific details?_

I honestly don't know. The most obvious thing I can think of is that it might
check the L1 cache size, which I believe can be discovered even if the
processor family is a new one that the JRE doesn't recognize.

~~~
zanny
cat /proc/cpuinfo. That is what the kernel says about the cpu, which is about
as much info as you are going to get without some database lookup on
specification data given a model number.

------
Cogito
_I want to really re-iterate how great Junio Hamano has been as a git
maintainer, and I haven't had to worry about git development for the last five
years or so. Junio has been an exemplary maintainer, and shown great taste_

Having listened in on the git developers mailing list for the last few years,
occasionally getting involved, I can re-iterate how true this is.

Sure, git development uses some anachronistic-feeling conventions (like mailed
patch-sets) but these all have reason behind them and exist because they work
for the people who are working on git.

I don't know how many of the processes are held over from before Junio got
involved, however both those processes and how Junio handles the entire thing
are a great case study on how open source can be done. Some entry points for
interested people:

[https://github.com/gitster/git/blob/master/Documentation/how...](https://github.com/gitster/git/blob/master/Documentation/howto/maintain-
git.txt)

[https://github.com/gitster/git/blob/master/Documentation/Sub...](https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches)

[https://github.com/gitster/git/blob/master/Documentation/Cod...](https://github.com/gitster/git/blob/master/Documentation/CodingGuidelines)

------
FrojoS
I found this interesting: " [...] I think that rotating storage is going the
way of the dodo (or the tape). [...] The latencies of rotational storage are
horrendous, and I personally refuse to use a machine that has those nasty
platters of spinning rust in them. [...] "

Is this about SSD vs. HDD? Does he favor SSD over HDD for Desktops?

Personally, my 99% use time computer is a MacAir with 256 GB SDD, and I love
how fast it is and that I don't have to worry about breaking a HDD. But having
so little disk space is definitely a limitation to me. I would have expected,
that Linus has a huge HDD in his desktop computer, maybe in combination with a
SDD for speedup.

Apart from price, isn't lifetime still a huge problem for SSDs? I was
expecting HDDs to die out for Laptops but to be around for a long time on
desktops.

~~~
davidw
> I would have expected, that Linus has a huge HDD in his desktop computer,
> maybe in combination with a SDD for speedup.

What for? The complete Linux git repository is less than one gig.

    
    
        /dev/sda1       141G   93G   42G  70% /
    

That's me. If you mostly just do coding, you don't need gigs and gigs of space
- for most things, at least. 256 GB would be more than enough for the
immediate future, so I'll definitely put an SDD in my next computer.

~~~
FrojoS
Yeah, that was my line of thinking, too.

Hasn't turned out to be true for me. The 256 GB are quite limiting to me.

Things that eat up a lot of space on my SSD:

\- eMail: dozen's of GB, but I wan't to be able to read them offline \-
Virtual Machine, I run Windows 7 with 50 GB allocated space \- clumsy programs
which eat a lot of disk space like Visual Studio \- Videos that I record from
experiments \- recorded data from said experiments - when you record at 1kHz
space goes up fast \- mp3 music

~~~
davidw
So, basically things that gobble space are:

* Audio and video files. That's to be expected.

* Windows.

My guess is that Linus doesn't have much to do with the latter, and probably
doesn't use his work computer for the former.

~~~
Evbn
He explicitly said to put media on a NAS disk.

------
bryanlarsen
Anybody else notice the date animation and mouse over text for same?

~~~
thenextcorner
Off Topic: For Slashdot's 15 years anniversary, in the month of October,
everyday there is a different community submitted logo on Slashdot!

All these Interviews are done for the 15 yrs anniversary as well with famous
Slashdot active users...Today Linus, last week Wozniak:
[http://apple.slashdot.org/story/12/10/01/1527257/ask-
steve-w...](http://apple.slashdot.org/story/12/10/01/1527257/ask-steve-
wozniak-anything)

------
B-Con
FTA:

> People were apparently surprised by me saying that copyrights had problems
> too. I don't understand why people were that surprised, but I understand
> even _less_ why people then thought that "copyrights have problems" would
> imply "copyright protection should be abolished". The second doesn't follow
> at all.

> Quite frankly, there are a lot of f*cking morons on the internet.

I have to admit that I think pretty much the same thing whenever I read
discussions about patent/copyright law on the Internet.

------
wissler
_Btw, it's not just microkernels. Any time you have "one overriding idea", and
push your idea as a superior ideology, you're going to be wrong. Microkernels
had one such ideology, there have been others. It's all BS. The fact is,
reality is complicated, and not amenable to the "one large idea" model of
problem solving. The only way that problems get solved in real life is with a
lot of hard work on getting the details right. Not by some over-arching
ideology that somehow magically makes things work._

Yes, well, Torvalds is here disputing one of the main drivers of science, the
motive that brought us Newtonian physics, quantum mechanics, you know, the
very things he depends on via his use of microprocessor technology.

If your "one overriding idea" is wrong, then certainly that'll get you into
trouble, but as history demonstrates, they aren't always wrong. They are
always hard to come up with, and often when you come up with them you face an
uphill battle with people who want to maintain the status quo and who can't
conceive of "one big idea." But eventually those ideas are the ones that cause
tectonic shifts in human progress.

His reference to Edison is apt. It wasn't Edison who brought us the AC motor
that literally revolutionized power distribution and the whole industrialized
world. It was a man who thought big, who had "one overriding idea": Tesla.

~~~
dude_abides
Physicists' job is to come up with "one overriding idea". But engineers know
"one overriding idea" never works except in theory, and that the devil is in
the details.

Linus is not saying that microkernels are architecturally bad. He concedes
that it is an architecturally superior idea but it is not a panacea when it
comes to OS design. It merely shifts inefficiency outside the kernel.

~~~
wissler
_But engineers know "one overriding idea" never works except in theory_

On the contrary, good engineers are not dogmatists. They're open to new ideas
and strive for simplicity, which means striving for unified approaches based
on empirical reasoning. See Newton.

~~~
maratd
Your continued comparison of physics to software engineering is horribly
flawed.

Software engineering is about creating something for _humans_ while working
with other _humans_. It is a science that is primarily constrained by human
nature.

Physics is about describing _reality_. It is a science that is primarily
constrained by reality.

In software engineering, it is always better to choose a flawed technical
solution that leads to less friction among _humans_. Because less friction
among _humans_ is the entire point of software engineering.

~~~
dxbydt
I am genuinely curious how anything technically superior ever gets a chance in
this concocted world of yours. Clearly, you prize "less friction among humans"
above all else. So given a choice between a clearly flawed technical solution
( say building an operating system in PHP) and alienating other humans (
specifically, an office full of PHP experts ), we should build the OS in PHP
because that leads to less friction among humans...yeah ? Let me know how that
goes...

Back on point, In grad school, we read the Tenenbaum-Torvalds debates in OS
class to get an idea of the current state of research. Tenenbaum's point,
among other things, was that microkernels were an unsolved problem. Granted
they pushed the problem space into communication, and you had to contend with
latencies....but that was the whole prize, to solve this brand new problem
space. Whereas big bad monolithic OSes were a solved problem. We know they
could be done. As far as a CS researcher was concerned, there was no meat in
that space...it was mostly implementation detail and optimizing. Whereas
microkernels, despite being a cleaner, more elegant approach to OS design,
clearly had tons of issues to be solved, and whoever took a stab at them would
push the state of the art forward. That is the point => to find a superior
technical solution, not minimizing friction among humans.

~~~
wissler
I'm glad to see someone getting the point, which is that we as scientists
strive for simplified, unified explanations and systems, and that's a _good_
thing.

Linux is nice and practical, but try working with it as a systems programmer
sometime. It's full of hacks and arbitrary complexity and all manner of
nonsense that persists year after year.

~~~
shasta
I hate all the existing OSes for this reason. Unfortunately, it's easier to
crowd source a big pile of dung (sure you can help - just pick up a shovel!)
than it is to build something elegant.

~~~
adestefan
The problem is that even the most beautiful and simple solutions end up
turning into a big pile of dung to actually be useful in the real world. You
get to the 80% point and then all of a sudden you realize that to do the next
thing you need one little hack here. Now you get to 85% and you realize you
need one more little hack, then at 88% you need another little hack to make it
speedy, ...

~~~
wissler
_The problem is that even the most beautiful and simple solutions end up
turning into a big pile of dung_

Until they don't. You don't know what who is going to come up with next.

~~~
adestefan
Way to hack off the end of my sentence which is the most important part.

------
humdumb
I think we need more open source projects that are not open to contribution
from anyone. This may upset some people but will keep the bar for quality
high. Linus' original work has been tarnished by too many eager but
unqualified contributors.

If he had just chosen a small team, I think Linux could have been a real
contender to BSD in terms of quality. It would have taken time to do, but they
have had a loyal user base (of non-contributors) and demand from early on due
to the legal problems with obtaining BSD and that is I think what has pushed
Linux forward.

~~~
avar
You're asserting a lot of things without any specifics to back them up. I've
been using Linux-based systems for a long time and the quality of the kernel
has never posed any sort of practical issue for me.

If Linus had chosen a small team and taken his time to do anything I'm sure
the Linux kernel could have ended up like OpenBSD or similar systems. A very
high quality OS that takes its time to do everything to the point where users
more interested in a practical OS would have looked elsewhere.

~~~
humdumb
Could you define "practical OS"?

What specifically do you want this OS to be able to do? (Note that we've
reached a point where no user necesarily needs to restrict themselves to a
single OS. They could use different OS's on the same computer for different
purposes. This was not always so easy to do. It will continue to get easier.)

