9 ms·

Linus Torvalds Answers Your Questions

228 points by tmhedberg 14y ago

DigitalJack 14y ago
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.
- nine_k 14y ago
  Instead of pointing to a node, then dereferencing node's 'next' field, you can point directly to the 'next' field of a node (which is a pointer itself), and directly update it, as Linus shows. This eliminates the special handling of list head. // Trying to remember C syntax prev_link ** Node; // **prev_link == previous_node->next for (prev_link = &list_head; cur_entry = **prev_link; cur_entry != NULL) { if (must_remove(cur_entry)) { **prev_link = cur_entry->next; // exclude cur_entry break; } }
  - zanny 14y ago
    You have your syntax reversed, it would be Node prev_link, and cur_entry would be a Node* not a Node. Also your loop condition goes in the middle and the per-stage operation goes last. I still don't get what you are doing here, since previous never updated, it always points to the list_head. So you would be changing the first node to point to the node after the one you are removing, which means you remove all nodes after the first up through the to-be removed node since the head is now pointing to the next. Here's my stabs at it: node **prevNode, *nextNode; // Doesn't work, curr becomes null and can't reference next for(prevNode = &list_head, currNode = *prevNode; currNode != NULL; currNode = *prevNode, prevNode = &currNode->next) if(must_remove(**currNode) { **prevNode = currNode->next; *prevNode = NULL; } The only other way I could think to remove a singly linked list element is the dumb way: node *curr = list_head, *prev = NULL; for(; curr != NULL; prev = curr, curr = curr->next) { if(must_remove(*curr) { if(prev == NULL) list_head = curr->next; prev->next == curr->next; curr = NULL; } }
    - graue 14y ago
      You are setting currNode and prevNode in the wrong order in your loop incrementer. Also, the variable name "prevNode" is misleading because it is not the previous node, it's the link from the previous node to the current node. Let's change it to "prevLink". For the first iteration through your loop, prevLink = &list_head currNode = list_head Second, prevLink = list_head->next currNode = list_head /* (again) */ Third, prevLink = list_head->next->next currNode = list_head->next In other words, from the second iteration on, prevLink is actually nextLink, that is, currNode->next. Here's my take: typedef struct node { /* ...some fields... */ struct node *next; } Node; void foobar(Node *node_list) { Node **prev_link; Node *current_node; Node *list_head = node_list; for (current_node = list_head, prev_link = &list_head; current_node != NULL; prev_link = &(current_node->next), current_node = *prev_link) { /* ...do something... */ if (must_remove(current_node)) { *prev_link = current_node->next; free(current_node); } } } This code compiles with no warnings, so it must be perfect. :) The beauty of it is that by doing it this way, you don't need to special-case the list head at all. You could do something like foobar(&(actual_list_head->next)) and have foobar() run on every element except the first one, and it would just work.
      - zanny 14y ago
        That makes more sense, change the next pointer from the previous. Thanks!
      - tveita 14y ago
        This almost works, but the caller will not know when foobar() has deleted the list head, and you update prev_link to the current_node even if you have deleted that node Did you mean: void foobar(Node **prev_link) { Node *current_node; while((current_node = *prev_link) != NULL) { /* ...do something... */ if (must_remove(current_node)) { *prev_link = current_node->next; free(current_node); } else { prev_link = &(current_node->next); } } }
- ramLlama 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - fr0sty 14y ago
    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 14y ago
      Yes and then to set it would be *link = (*link)->next;
- chj 14y ago
  Actually I would vote for the simpler one. Branch predictor should take care of the optimization pretty well.
bryanlarsen 14y ago
Anybody else notice the date animation and mouse over text for same?
- thenextcorner 14y ago
  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-wozniak-anything http://apple.slashdot.org/story/12/10/01/1527257/ask-steve-w...
wissler 14y ago
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.
- m_for_monkey 14y ago
  No, scientists are coming from the opposite direction. Observing things, then draw conclusions and connect the dots. Pseudosciences, like homeopathy are backwards. They pull "universal truths" out of thin air, like "Law of similars", and after that they don't mind even if experiments and reality doesn't support these theories.
  - wissler 14y ago
    A true scientist seeks an integrated understanding. Newton related the objects that fall on Earth to the motion of the planets. One big sweeping idea for a wide range of phenomena. That's science.
    - koide 14y ago
      That's the science you like. There's plenty of science without sweeping ideas. There will likely always be.
mmariani 14y ago
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.
- wtetzner 14y ago
  Well, from your perspective it is not fun to use. I actually really enjoy using git.
- ramblerman 14y ago
  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.
  - envex 14y ago
    I'm going to second this, I love using git.
  - calpaterson 14y ago
    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 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".
    - _ikke_ 14y ago
      Most tool require you to learn an interface to operate, and not the internals. Git is quite the opposite. If you are learning a set of 'incantations', git will always seem hard to use. But if you take some time to learn how git works on the inside (which is really not that hard), it gets much easier to understand why and how you need to use a certain command. Some argue that this is why git is bad, but I'd argue that this in the end is a good thing, because it gives you so much more power. Learning how to use git is an investment, bit in my opinion an investment worthwhile.
humdumb 14y ago
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 14y ago
  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 14y ago
    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.)
    - deleted 14y ago
      [deleted]
  - rjsw 14y ago
    The code in the Linux kernel can make adding new features harder than it needs to be. The network stack is one area that could be better designed.
- MartinCron 14y ago
FrojoS 14y ago
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 14y ago
  > 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 14y ago
    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 14y ago
      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.
dkarl 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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.
- Evbn 14y ago
  Which is funny because that is the reason people choose Java and ML over C: to let the compiler do the optimization. But that doesn't always work.
Cogito 14y ago
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/howto/maintain-git.txt https://github.com/gitster/git/blob/master/Documentation/how... https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches https://github.com/gitster/git/blob/master/Documentation/Sub... https://github.com/gitster/git/blob/master/Documentation/CodingGuidelines https://github.com/gitster/git/blob/master/Documentation/Cod...
B-Con 14y ago
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.

228 points by tmhedberg 14y ago

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.

nine_k 14y ago
Instead of pointing to a node, then dereferencing node's 'next' field, you can point directly to the 'next' field of a node (which is a pointer itself), and directly update it, as Linus shows. This eliminates the special handling of list head. // Trying to remember C syntax prev_link ** Node; // **prev_link == previous_node->next for (prev_link = &list_head; cur_entry = **prev_link; cur_entry != NULL) { if (must_remove(cur_entry)) { **prev_link = cur_entry->next; // exclude cur_entry break; } }
- zanny 14y ago
  You have your syntax reversed, it would be Node prev_link, and cur_entry would be a Node* not a Node. Also your loop condition goes in the middle and the per-stage operation goes last. I still don't get what you are doing here, since previous never updated, it always points to the list_head. So you would be changing the first node to point to the node after the one you are removing, which means you remove all nodes after the first up through the to-be removed node since the head is now pointing to the next. Here's my stabs at it: node **prevNode, *nextNode; // Doesn't work, curr becomes null and can't reference next for(prevNode = &list_head, currNode = *prevNode; currNode != NULL; currNode = *prevNode, prevNode = &currNode->next) if(must_remove(**currNode) { **prevNode = currNode->next; *prevNode = NULL; } The only other way I could think to remove a singly linked list element is the dumb way: node *curr = list_head, *prev = NULL; for(; curr != NULL; prev = curr, curr = curr->next) { if(must_remove(*curr) { if(prev == NULL) list_head = curr->next; prev->next == curr->next; curr = NULL; } }
  - graue 14y ago
    You are setting currNode and prevNode in the wrong order in your loop incrementer. Also, the variable name "prevNode" is misleading because it is not the previous node, it's the link from the previous node to the current node. Let's change it to "prevLink". For the first iteration through your loop, prevLink = &list_head currNode = list_head Second, prevLink = list_head->next currNode = list_head /* (again) */ Third, prevLink = list_head->next->next currNode = list_head->next In other words, from the second iteration on, prevLink is actually nextLink, that is, currNode->next. Here's my take: typedef struct node { /* ...some fields... */ struct node *next; } Node; void foobar(Node *node_list) { Node **prev_link; Node *current_node; Node *list_head = node_list; for (current_node = list_head, prev_link = &list_head; current_node != NULL; prev_link = &(current_node->next), current_node = *prev_link) { /* ...do something... */ if (must_remove(current_node)) { *prev_link = current_node->next; free(current_node); } } } This code compiles with no warnings, so it must be perfect. :) The beauty of it is that by doing it this way, you don't need to special-case the list head at all. You could do something like foobar(&(actual_list_head->next)) and have foobar() run on every element except the first one, and it would just work.
    - zanny 14y ago
      That makes more sense, change the next pointer from the previous. Thanks!
    - tveita 14y ago
      This almost works, but the caller will not know when foobar() has deleted the list head, and you update prev_link to the current_node even if you have deleted that node Did you mean: void foobar(Node **prev_link) { Node *current_node; while((current_node = *prev_link) != NULL) { /* ...do something... */ if (must_remove(current_node)) { *prev_link = current_node->next; free(current_node); } else { prev_link = &(current_node->next); } } }
ramLlama 14y ago
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.
- deleted 14y ago
  [deleted]
- fr0sty 14y ago
  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 14y ago
    Yes and then to set it would be *link = (*link)->next;
chj 14y ago
Actually I would vote for the simpler one. Branch predictor should take care of the optimization pretty well.

bryanlarsen 14y ago

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

thenextcorner 14y ago
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-wozniak-anything http://apple.slashdot.org/story/12/10/01/1527257/ask-steve-w...

wissler 14y ago

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.

m_for_monkey 14y ago
No, scientists are coming from the opposite direction. Observing things, then draw conclusions and connect the dots. Pseudosciences, like homeopathy are backwards. They pull "universal truths" out of thin air, like "Law of similars", and after that they don't mind even if experiments and reality doesn't support these theories.
- wissler 14y ago
  A true scientist seeks an integrated understanding. Newton related the objects that fall on Earth to the motion of the planets. One big sweeping idea for a wide range of phenomena. That's science.
  - koide 14y ago
    That's the science you like. There's plenty of science without sweeping ideas. There will likely always be.

mmariani 14y ago

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.

wtetzner 14y ago
Well, from your perspective it is not fun to use. I actually really enjoy using git.
ramblerman 14y ago
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.
- envex 14y ago
  I'm going to second this, I love using git.
- calpaterson 14y ago
  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 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".
  - _ikke_ 14y ago
    Most tool require you to learn an interface to operate, and not the internals. Git is quite the opposite. If you are learning a set of 'incantations', git will always seem hard to use. But if you take some time to learn how git works on the inside (which is really not that hard), it gets much easier to understand why and how you need to use a certain command. Some argue that this is why git is bad, but I'd argue that this in the end is a good thing, because it gives you so much more power. Learning how to use git is an investment, bit in my opinion an investment worthwhile.

humdumb 14y ago

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 14y ago
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 14y ago
  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.)
  - deleted 14y ago
    [deleted]
- rjsw 14y ago
  The code in the Linux kernel can make adding new features harder than it needs to be. The network stack is one area that could be better designed.
MartinCron 14y ago

FrojoS 14y ago

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 14y ago
> 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 14y ago
  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 14y ago
    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.

dkarl 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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.
Evbn 14y ago
Which is funny because that is the reason people choose Java and ML over C: to let the compiler do the optimization. But that doesn't always work.

Cogito 14y ago

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/howto/maintain-git.txt https://github.com/gitster/git/blob/master/Documentation/how... https://github.com/gitster/git/blob/master/Documentation/SubmittingPatches https://github.com/gitster/git/blob/master/Documentation/Sub... https://github.com/gitster/git/blob/master/Documentation/CodingGuidelines https://github.com/gitster/git/blob/master/Documentation/Cod...

B-Con 14y ago

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.