Slashdot Mirror
Linus Torvalds Answers Your Questions
Monday you had a chance to ask Linus Torvalds any question you wanted. We sent him a dozen of the highest rated and below you'll see what he has to say about computers, programming, books, and copyrights. He also talks about what he would have done differently with Linux if he had to do it all over again. Hint: it rhymes with nothing.
The Absolute Death of Software Copyright?
by eldavojohn
Recently you spoke out about software patents and the patent process. But I was interested in what you said about how "nasty" copyright issues could get. You use SCO as the obvious nightmare case but what about violations against open source licenses like the GPLv3? Would you care if someone forked the Linux kernel and made major modifications to it and started selling it without releasing the code to the customers? What does your ideal situation look like for open source and commercial closed source? Would you just copy the Finnish model and aren't you afraid American experts are just as daft as American juries?
Linus: So I like copyrights, and even on patents I'm not necessarily in the "Patents are completely evil" camp. When I rant about patents or copyrights, I rant against the *excesses* and the bad policies, not about them existing in the first place.
The patent problems people on slashdot are probably familiar with: the system is pretty much geared towards people abusing it, with absolutely ridiculous patents being admitted, and it hindering invention rather than helping it. The failures are many, and I don't know how to fix it, but much stricter limits on what can be patented are clearly needed.
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.
Anyway, the problems with copyright come from absurdly long protection periods, and some overly crazy enforcement. And don't get me wrong: I don't actually think that these problems show up all that much in the software industry. The case of SCO was not, I think, so much a failure of copyright law itself: sure, it was annoying, but at the same time it was really more about a psychopathic company with a failed business that tried to game the system. Tried, and lost. And yes, that fiasco took much too long, and was much too expensive, and should have been shut down immediately, but that whole "using the law for harassment" in the US is a separate issue independent of the copyright issues.
No, when I stated that copyright protection is too strong, I was talking about things like "life of author+70 years" and the corporate 95-year version. That's *ridiculous*. Couple that with the difficulty of judging fair use etc, and it really hinders things like archival of material, making of documentaries, yadda yadda...
So I personally think that IP protection isn't evil in itself - but that it turns evil when it is taken too far. And both patent protection and copyright protection has been taken much much too far.
Scale the term limits back to fifteen years or so, and copyrights would be much better.
When I'm designing a processor for Linux.
by Art Popp (29075)
I spend some time designing things in Verilog and trying to read other people's source code at opencores.org, and I recall you did some work at Transmeta. For some time I've had a list of instructions that could be added to processors that would be drastically speed up common functions, and SSE 4.2 includes some of my favorites, the dqword string comparison instructions. So...What are your ideas for instructions that you've always thought should be handled by the processor, but never seen implemented?
Linus: I actually am not a huge fan of shiny new features. In processor design - as in so much of technology - what matters more is interoperability and compatibility. I realize that this makes people sad, because people are always chasing that cool new feature, but hey, in the end, technology is about doing useful things. And building and extending on top of existing knowledge and infrastructure is how 99% of all improvement gets done.
The occasional big shift and really new thing might get all the attention, but it seldom really is what matters. I like to quote Thomas Edison: "Genius is 1% inspiration, 99% perspiration". And that very much covers CPU architecture too: the inspiration is simply not as important as executing well. Sure, you need some inspiration, but you really don't need all that *much* of it.
So in CPU design, what should really be looked at is how well the CPU is able to do what we expect. The instruction set is important - but it is important mainly as a "I can run the same instructions the previous CPU did, so I can run all your programs without you having to do any extra work" issue - not as a "what new cool feature would you want in an instruction set".
To a CPU architect, I'd tell them to do the best they damn well can in the memory subsystem, for example. Regardless of instruction set, you'll want a great memory subsystem end-to-end. And I don't just mean good caches, but good *everything*. It's a hell of a lot of detail (perspiration), and I guarantee you that it will take a large team of people many generations to do really well on it. There is no simple silver bullet with a cool new instruction that will solve it for you.
And don't get me wrong - it's not *all* about the memory subsystem. It's about all the other details too.
Now, when it comes to actual instructions, I do tend to think that the world has shifted away from RISC. I'm a big believer in being good at running existing binaries across many different micro-architectures - the whole "compatibility" thing. And as a result, I think fragile architectures that depend on static instruction scheduling or run in-order are simply insane. If your CPU requires instruction scheduling for one particular set of instruction latencies or decoder limitations, your CPU is bad. I detested Itanium, for this reason - exposing the microarchitecture in the instruction set is just insane.
No, I want out-of-order and "high-level" instructions that actually work across different implementations of the same ISA, and across different classes of hardware (iow, span the whole "low-power embedded" to "high-end server" CPU range). So for example, I think having a "memcpy" or "memset" instruction is a great idea, if it allows you to have something that works optimally for different memory subsystems and microarchitectures.
As an example of what *not* to do, is to expose direct cacheline access with some idiotic "DCBZ" instruction that clears them - because that will then make the software have to care about the size of the cacheline etc. Same goes for things like "nontemporal accesses" that bypass the L1 cache - how do you know when to use those in software when different CPU's have different cache subsystems? Software just shouldn't care. Software wants to clear memory, not aligned cachelines, and software does *not* want to have to worry about how to do that most efficiently on some particular new machine with a particular cache size and memory subsystem.
What would you have done differently?
by Rob Kaper
It's been over twenty years since the inception of Linux. With 20/20 hindsight, what you have done differently if you had had today's knowledge and experience back in the early days?
Linus: I get asked this quite often, and I really don't see how I could possibly have done anything better. And I'm not claiming some kind of great forethought - it's just that with 20:20 hindsight, I really did choose the right big things. I still love the GPLv2, and absolutely think that making Linux open source was the greatest thing ever.
Have I made mistakes? Sure. But on the whole, I think Linux has done incredibly well, and I've made the right decisions around it (and the big things have *occasionally* been about technical issues, but more often about non-technical things like "Don't work for a commercial Linux company even if it seems like such a natural thing to do - keep working in a neutral place so that people can continue to work with me")
Monolithic vs. Micro-kernel architecture
by NoNeeeed
Has there ever been a time in the development of the Linux Kernel where you've wished you'd gone the Hurd-style micro-kernel route espoused by the like of Tannenbaum, or do you feel that from an architectural standpoint Linux has benefited from having a monolithic design?
Linux has been massively more successful than Hurd, but I wonder how much of that is down to intrinsic technical superiority of its approach, and how much to the lack of a central driving force supported by a community of committed developers? It always seemed like the Hurd model should have allowed more people to be involved, but that has never seemed to be the case.
Linus: I think microkernels are stupid. They push the problem space into *communication*, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix. They also lead to horrible extra complexity as you then have to fight the microkernel model, and make up new ways to avoid the extra communication latencies etc. Hurd is a great example of this kind of suckiness, where people made up whole new memory mapping models just because the normal "just make a quick system call within the same context" model had been broken by the microkernel model.
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.
Avoiding the Unix Wars
by dkleinsc
Why do you think Linux has been able to (mostly) avoid the fragmentation that plagued the competing Unixes of the 1980's? What would you say helps keep Linux a unified project rather than more forked system like BSD?
Linus: So I'm a huge believer in the GPLv2, and I really do believe the license matters. And what - to me - is important for an open-source license is not whether you can fork (which the BSD's allow), but whether the license encourages merging things back.
And btw, before people go all "license flamewar" on me, I would like to really emphasize the "to me" part. Licensing is a personal choice, and there is no "wrong" choice. For projects *I* care about, and that I started and can make the licensing decision for, I think the GPLv2 is the right thing to do for various reasons. But that does *not* mean that if somebody else makes another choice for his or her code, that wouldn't be the right choice for *that* person.
For example, I'd use a BSD-like license for code that I simply didn't care about, and wanted to just "push out there in case somebody else wants to use it". And I don't think proprietary licenses are evil either. It's all fine, it's up to the original author to decide what direction you want to do in.
Anyway, to just get back to the question - I really do think that encouraging merging is the most important part for a license for me. And having a license like the GPLv2 that basically *requires* everybody to have the right to merge back useful code is a great thing, and avoids the worry of forking.
And I do want to say that it's not that forking is bad. Forking is absolutely *required*, because easy forking is how development gets done. In fact, one of the design principles behind git was to make forking easy, and not have any technical barrier (like a "more central repository") that held back forking. Forking is important, and forking needs to happen any time there is a developer who thinks that they can do a better job in some area. Go wild, fork the project, and prove your point. Show everybody that you can make improvements.
But forking becomes a problem if there is no good way to merge things back. And in Linux, it's not been just about the license.Sure, the license means that legally we can always merge back the forks if they prove to be good forks. But we have also had a culture of encouraging forking and making forking be something that isn't acrimonious. Basically *all* the Linux distributions have had their own "forks" of the kernel, and it's not been seen as something bad, it's been seen as something natural and *good*. Which means that now the fork is all amicable and friendly, and there are not only no legal issues with merging it back into mainline, but there are also generally no big personality clashes or bad feelings about it either.
So it's not that Linux doesn't fork, it's that we've tried to make forks small and painless, and tried to be good about merging things back. Sure, there are disagreements, but they get resolved. Look at the Android work, for example: yeah, it wasn't all happy people and no problems, and it took a while, but most of it got merged back, and without excessively bad feelings, I think.
GIT
by vlm
If you had to do GIT over again, what, if anything, would you change?VERY closely related question, do you like the git-flow project and would you think about pulling that into mainline or not?
Linus: So there's been a few small details that I think we could have done better, but on the whole I'm *very* happy with git. I think the core design is very solid, and we have almost zero redundant information, and the core model is really built around a few solid concepts that make a lot of sense. Git is very unix-like in that it has a few basic design things ("everything is an object" with a few basic relationships between the different objects in the git database) and then a lot of utility is built up around that whole thing.
So I'm very proud of git. I think I did a great design, and then others (and Junio Hamano in particular) have taken that great design and really run with it. Sure, 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, and I really think it got the fundamentals right, in ways that SCM's that came before did not.
As to git-flow, 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. And because I don't need to, I haven't even followed some of the projects around git, like git-flow. It's not what I need for *my* git workflow, but if it helps people maintain a good topic-branch model with git, then all the more power to them. And whether it should go into mainline git or not, I won't even comment on, because I absolutely trust that Junio will make the right decision.
Storage advancements in the kernel?
by ScuttleMonkey
Now that Ceph is gathering momentum since having been included in the mainline kernel, what other storage (or low level) advancements do you see on the horizon? (full disclosure: I work for Inktank now, the consulting/services company that employs most of the core Ceph engineers)
Linus: I'm not actually all that much of a storage guy, and while I'm the top-level kernel maintainer, this is likely a question that would be better asked of a number of other people.
The one (personal) thing storage-related that I'd like to re-iterate is that I think that rotating storage is going the way of the dodo (or the tape). "How do I hate thee, let me count the ways". 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.
Sure, maybe those rotating platters are ok in some NAS box that you keep your big media files on (or in that cloud storage cluster you use, and where the network latencies make the disk latencies be secondary), but in an actual computer? Ugh. "Get thee behind me, Satan".
That didn't answer the question you really asked, but I really don't tend to get all that excited about storage in general.
favorite hack
by vlm
I asked a bunch of hard architecture questions, now for a softball Q. Your favorite hack WRT kernel internals and kernel programming in general. drivers, innards, I don't care which. The kind of thing where you took a look at the code and go 'holy cow that's cool' or whatever. You define favorite, hack, and kernel. Just wanting to kick back and hear a story about cool code.
Linus: Hmm. You do realize that I don't get all that close to the code any more? I spend my time not coding, but reading emails, and merging stuff others wrote. And when I *do* get involved with the code, it's not because it's "cool", it's because it broke, and you'll find me cursing the people who wrote it, and questioning their parentage and that of their pets.
So I very seldom get involved in the really cool code any more, I'm afraid. I end up being involved in the "Holy sh*t, how did we ever merge that cr*p" code. Perhaps not as much as Greg (who has to deal with the staging tree), but then Greg is "special".
That said, we do have lots of pretty cool code in the kernel. I'm particularly proud of our filename lookup cache, but hey, I'm biased. That code is *not* for the weak of heart, though, because the whole lockless lookup (with fallbacks to more traditional locked code) is hairy and subtle, and mortals are not supposed to really look at it. It's been tweaked to some pretty extreme degrees, because it ends up being involved any time you look up a filename. I still remember how happy I was to merge the new lockless RCU filename lookup code last year.
At the opposite end of the spectrum, I actually wish more people understood the really core low-level kind of coding. Not big, complex stuff like the lockless name lookup, but simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev)
prev->next = entry->next;
else
list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
So there's lots of pride in doing the small details right. It may not be big and important code, but I do like seeing code where people really thought about the details, and clearly also were thinking about the compiler being able to generate efficient code (rather than hoping that the compiler is so smart that it can make efficient code *despite* the state of the original source code).
Books, Books, Books
by eldavojohn
As a software developer, I have a coveted collection of books. A few of said tomes -- both fiction and non -- have fundamentally altered the course of my life. Assuming yours aren't just man pages and .txt files, what are they?
Linus: I read a fair amount, but I have to admit that for me reading tends to be about escapism, and books to me are mostly forgettable. I can't really think of a single case of a book that struck me as life-changing, the way some people apparently find some book that really changed the way they think.
That said, I'll point to a couple of books I really enjoyed. On the non-fiction side, Richard Dawkin's "The Selfish Gene" was one book that I think is pretty influential. On the fiction side, as a teenager I enjoyed Heinlein's "Stranger in a strange land" a lot, and I have to admit to "Lord of the Rings" having been pretty important to me - but for a slightly odd reason, not as a huge Tolkien fan. For me, it was one of the first "real" books I read in English, and I started with a dictionary by my side, and ended it reading without needing one.
These days, I still read crap. I like my Kindle, and often read the self-published stuff for 99c. There are some real stinkers in there, but there's been a lot of "that was certainly worth the 99c" stuff too. I've also enjoyed just re-reading some of the classics I grew up with - I just re-read both the Count of Monte Cristo and the Three Musketeers, for example.
How do you deal with burn-out?
by kallisti5
You must of been burned out on Linux kernel development multiple-times over by now... how do you deal with it?
Linus: Oh, I really enjoy what I do. And I actually enjoy arguing too, and while I may swear a lot and appear like a grumpy angry old man at times, I am also pretty good at just letting things go. So I can be very passionate about some things, but at the same time I don't tend to really hold on to some particular issue for too long, and I think that helps avoid burn-out.
Obsessing about things is important, and things really do matter, but if you can't let go of them, you'll end up crazy.
So to me, some of the occasional flame-wars are really just invigorating. And the technology and the use cases end up changing enough that things never get *boring*, so I actually have not been close to burning out very often.
The one really painful time was some time during the middle of the 2.4.x series (about ten years ago), before I got to hand it over to stable maintenance, and we really had a lot of problems going on. You can google for "Linus doesn't scale" and various other threads about the problems we had back then, and it really was pretty painful. The kernel was growing and I wasn't keeping up, and BitKeeper and some fairly painful process changes really ended up helping a lot.
Describe your computer
by twistedcubic
Can you describe in detail your home and work computers, including processor, motherboard, and graphics card? And also say something about their compatibility with Linux?
Linus: My home computer isn't actually all that interesting: I don't need all that much CPU power any more, and for the last several years, my primary requirement (since CPU's are fast enough) has been that the system be really really quiet, and that it has a good SSD in it. If our cat deigns to jump into my lap while I'm working, the loudest noise in the room should be the purring of the cat, not the computer.
So my main desktop is actually a 4-core Westmere machine, not really anything special. The most unusual part of the machine is probably just the fact that it has a good case (I forget the exact case name now) which avoids rattling etc. And one of the bigger Intel SSD's. I think I'll be upgrading some time this fall, but I will have had that machine for two years now, I think.
My laptop (that I'm writing this with, since I'm traveling in Japan and Korea right now) is an 11" Apple Macbook Air from last year (but running Linux, of course - no OS X anywhere), because I really hate big laptops. I can't understand people who lug around 15" (or 17"!) monsters. The right weight for a laptop is 1kg, no more.
Re:The End
by Narnie
Speaking of ends, one day you'll pass on your duties. How do you envision the kernel and the Linux ecosystem after passing your reigns?
Linus: Oh, the kernel really has a very solid development community, I wouldn't worry about it. We've got several "top lieutenants" that could take over, and I'd worry much more about many other open-source projects that don't have nearly the same kind of big development community that the kernel does.
That said, I've been doing this for over twenty years now, and I don't really see myself stopping. I still do like what I'm doing, and I'd just be bored out of my gourd without the kernel to hack on.
by eldavojohn
Recently you spoke out about software patents and the patent process. But I was interested in what you said about how "nasty" copyright issues could get. You use SCO as the obvious nightmare case but what about violations against open source licenses like the GPLv3? Would you care if someone forked the Linux kernel and made major modifications to it and started selling it without releasing the code to the customers? What does your ideal situation look like for open source and commercial closed source? Would you just copy the Finnish model and aren't you afraid American experts are just as daft as American juries?
Linus: So I like copyrights, and even on patents I'm not necessarily in the "Patents are completely evil" camp. When I rant about patents or copyrights, I rant against the *excesses* and the bad policies, not about them existing in the first place.
The patent problems people on slashdot are probably familiar with: the system is pretty much geared towards people abusing it, with absolutely ridiculous patents being admitted, and it hindering invention rather than helping it. The failures are many, and I don't know how to fix it, but much stricter limits on what can be patented are clearly needed.
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.
Anyway, the problems with copyright come from absurdly long protection periods, and some overly crazy enforcement. And don't get me wrong: I don't actually think that these problems show up all that much in the software industry. The case of SCO was not, I think, so much a failure of copyright law itself: sure, it was annoying, but at the same time it was really more about a psychopathic company with a failed business that tried to game the system. Tried, and lost. And yes, that fiasco took much too long, and was much too expensive, and should have been shut down immediately, but that whole "using the law for harassment" in the US is a separate issue independent of the copyright issues.
No, when I stated that copyright protection is too strong, I was talking about things like "life of author+70 years" and the corporate 95-year version. That's *ridiculous*. Couple that with the difficulty of judging fair use etc, and it really hinders things like archival of material, making of documentaries, yadda yadda...
So I personally think that IP protection isn't evil in itself - but that it turns evil when it is taken too far. And both patent protection and copyright protection has been taken much much too far.
Scale the term limits back to fifteen years or so, and copyrights would be much better.
When I'm designing a processor for Linux.
by Art Popp (29075)
I spend some time designing things in Verilog and trying to read other people's source code at opencores.org, and I recall you did some work at Transmeta. For some time I've had a list of instructions that could be added to processors that would be drastically speed up common functions, and SSE 4.2 includes some of my favorites, the dqword string comparison instructions. So...What are your ideas for instructions that you've always thought should be handled by the processor, but never seen implemented?
Linus: I actually am not a huge fan of shiny new features. In processor design - as in so much of technology - what matters more is interoperability and compatibility. I realize that this makes people sad, because people are always chasing that cool new feature, but hey, in the end, technology is about doing useful things. And building and extending on top of existing knowledge and infrastructure is how 99% of all improvement gets done.
The occasional big shift and really new thing might get all the attention, but it seldom really is what matters. I like to quote Thomas Edison: "Genius is 1% inspiration, 99% perspiration". And that very much covers CPU architecture too: the inspiration is simply not as important as executing well. Sure, you need some inspiration, but you really don't need all that *much* of it.
So in CPU design, what should really be looked at is how well the CPU is able to do what we expect. The instruction set is important - but it is important mainly as a "I can run the same instructions the previous CPU did, so I can run all your programs without you having to do any extra work" issue - not as a "what new cool feature would you want in an instruction set".
To a CPU architect, I'd tell them to do the best they damn well can in the memory subsystem, for example. Regardless of instruction set, you'll want a great memory subsystem end-to-end. And I don't just mean good caches, but good *everything*. It's a hell of a lot of detail (perspiration), and I guarantee you that it will take a large team of people many generations to do really well on it. There is no simple silver bullet with a cool new instruction that will solve it for you.
And don't get me wrong - it's not *all* about the memory subsystem. It's about all the other details too.
Now, when it comes to actual instructions, I do tend to think that the world has shifted away from RISC. I'm a big believer in being good at running existing binaries across many different micro-architectures - the whole "compatibility" thing. And as a result, I think fragile architectures that depend on static instruction scheduling or run in-order are simply insane. If your CPU requires instruction scheduling for one particular set of instruction latencies or decoder limitations, your CPU is bad. I detested Itanium, for this reason - exposing the microarchitecture in the instruction set is just insane.
No, I want out-of-order and "high-level" instructions that actually work across different implementations of the same ISA, and across different classes of hardware (iow, span the whole "low-power embedded" to "high-end server" CPU range). So for example, I think having a "memcpy" or "memset" instruction is a great idea, if it allows you to have something that works optimally for different memory subsystems and microarchitectures.
As an example of what *not* to do, is to expose direct cacheline access with some idiotic "DCBZ" instruction that clears them - because that will then make the software have to care about the size of the cacheline etc. Same goes for things like "nontemporal accesses" that bypass the L1 cache - how do you know when to use those in software when different CPU's have different cache subsystems? Software just shouldn't care. Software wants to clear memory, not aligned cachelines, and software does *not* want to have to worry about how to do that most efficiently on some particular new machine with a particular cache size and memory subsystem.
What would you have done differently?
by Rob Kaper
It's been over twenty years since the inception of Linux. With 20/20 hindsight, what you have done differently if you had had today's knowledge and experience back in the early days?
Linus: I get asked this quite often, and I really don't see how I could possibly have done anything better. And I'm not claiming some kind of great forethought - it's just that with 20:20 hindsight, I really did choose the right big things. I still love the GPLv2, and absolutely think that making Linux open source was the greatest thing ever.
Have I made mistakes? Sure. But on the whole, I think Linux has done incredibly well, and I've made the right decisions around it (and the big things have *occasionally* been about technical issues, but more often about non-technical things like "Don't work for a commercial Linux company even if it seems like such a natural thing to do - keep working in a neutral place so that people can continue to work with me")
Monolithic vs. Micro-kernel architecture
by NoNeeeed
Has there ever been a time in the development of the Linux Kernel where you've wished you'd gone the Hurd-style micro-kernel route espoused by the like of Tannenbaum, or do you feel that from an architectural standpoint Linux has benefited from having a monolithic design?
Linux has been massively more successful than Hurd, but I wonder how much of that is down to intrinsic technical superiority of its approach, and how much to the lack of a central driving force supported by a community of committed developers? It always seemed like the Hurd model should have allowed more people to be involved, but that has never seemed to be the case.
Linus: I think microkernels are stupid. They push the problem space into *communication*, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix. They also lead to horrible extra complexity as you then have to fight the microkernel model, and make up new ways to avoid the extra communication latencies etc. Hurd is a great example of this kind of suckiness, where people made up whole new memory mapping models just because the normal "just make a quick system call within the same context" model had been broken by the microkernel model.
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.
Avoiding the Unix Wars
by dkleinsc
Why do you think Linux has been able to (mostly) avoid the fragmentation that plagued the competing Unixes of the 1980's? What would you say helps keep Linux a unified project rather than more forked system like BSD?
Linus: So I'm a huge believer in the GPLv2, and I really do believe the license matters. And what - to me - is important for an open-source license is not whether you can fork (which the BSD's allow), but whether the license encourages merging things back.
And btw, before people go all "license flamewar" on me, I would like to really emphasize the "to me" part. Licensing is a personal choice, and there is no "wrong" choice. For projects *I* care about, and that I started and can make the licensing decision for, I think the GPLv2 is the right thing to do for various reasons. But that does *not* mean that if somebody else makes another choice for his or her code, that wouldn't be the right choice for *that* person.
For example, I'd use a BSD-like license for code that I simply didn't care about, and wanted to just "push out there in case somebody else wants to use it". And I don't think proprietary licenses are evil either. It's all fine, it's up to the original author to decide what direction you want to do in.
Anyway, to just get back to the question - I really do think that encouraging merging is the most important part for a license for me. And having a license like the GPLv2 that basically *requires* everybody to have the right to merge back useful code is a great thing, and avoids the worry of forking.
And I do want to say that it's not that forking is bad. Forking is absolutely *required*, because easy forking is how development gets done. In fact, one of the design principles behind git was to make forking easy, and not have any technical barrier (like a "more central repository") that held back forking. Forking is important, and forking needs to happen any time there is a developer who thinks that they can do a better job in some area. Go wild, fork the project, and prove your point. Show everybody that you can make improvements.
But forking becomes a problem if there is no good way to merge things back. And in Linux, it's not been just about the license.Sure, the license means that legally we can always merge back the forks if they prove to be good forks. But we have also had a culture of encouraging forking and making forking be something that isn't acrimonious. Basically *all* the Linux distributions have had their own "forks" of the kernel, and it's not been seen as something bad, it's been seen as something natural and *good*. Which means that now the fork is all amicable and friendly, and there are not only no legal issues with merging it back into mainline, but there are also generally no big personality clashes or bad feelings about it either.
So it's not that Linux doesn't fork, it's that we've tried to make forks small and painless, and tried to be good about merging things back. Sure, there are disagreements, but they get resolved. Look at the Android work, for example: yeah, it wasn't all happy people and no problems, and it took a while, but most of it got merged back, and without excessively bad feelings, I think.
GIT
by vlm
If you had to do GIT over again, what, if anything, would you change?VERY closely related question, do you like the git-flow project and would you think about pulling that into mainline or not?
Linus: So there's been a few small details that I think we could have done better, but on the whole I'm *very* happy with git. I think the core design is very solid, and we have almost zero redundant information, and the core model is really built around a few solid concepts that make a lot of sense. Git is very unix-like in that it has a few basic design things ("everything is an object" with a few basic relationships between the different objects in the git database) and then a lot of utility is built up around that whole thing.
So I'm very proud of git. I think I did a great design, and then others (and Junio Hamano in particular) have taken that great design and really run with it. Sure, 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, and I really think it got the fundamentals right, in ways that SCM's that came before did not.
As to git-flow, 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. And because I don't need to, I haven't even followed some of the projects around git, like git-flow. It's not what I need for *my* git workflow, but if it helps people maintain a good topic-branch model with git, then all the more power to them. And whether it should go into mainline git or not, I won't even comment on, because I absolutely trust that Junio will make the right decision.
Storage advancements in the kernel?
by ScuttleMonkey
Now that Ceph is gathering momentum since having been included in the mainline kernel, what other storage (or low level) advancements do you see on the horizon? (full disclosure: I work for Inktank now, the consulting/services company that employs most of the core Ceph engineers)
Linus: I'm not actually all that much of a storage guy, and while I'm the top-level kernel maintainer, this is likely a question that would be better asked of a number of other people.
The one (personal) thing storage-related that I'd like to re-iterate is that I think that rotating storage is going the way of the dodo (or the tape). "How do I hate thee, let me count the ways". 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.
Sure, maybe those rotating platters are ok in some NAS box that you keep your big media files on (or in that cloud storage cluster you use, and where the network latencies make the disk latencies be secondary), but in an actual computer? Ugh. "Get thee behind me, Satan".
That didn't answer the question you really asked, but I really don't tend to get all that excited about storage in general.
favorite hack
by vlm
I asked a bunch of hard architecture questions, now for a softball Q. Your favorite hack WRT kernel internals and kernel programming in general. drivers, innards, I don't care which. The kind of thing where you took a look at the code and go 'holy cow that's cool' or whatever. You define favorite, hack, and kernel. Just wanting to kick back and hear a story about cool code.
Linus: Hmm. You do realize that I don't get all that close to the code any more? I spend my time not coding, but reading emails, and merging stuff others wrote. And when I *do* get involved with the code, it's not because it's "cool", it's because it broke, and you'll find me cursing the people who wrote it, and questioning their parentage and that of their pets.
So I very seldom get involved in the really cool code any more, I'm afraid. I end up being involved in the "Holy sh*t, how did we ever merge that cr*p" code. Perhaps not as much as Greg (who has to deal with the staging tree), but then Greg is "special".
That said, we do have lots of pretty cool code in the kernel. I'm particularly proud of our filename lookup cache, but hey, I'm biased. That code is *not* for the weak of heart, though, because the whole lockless lookup (with fallbacks to more traditional locked code) is hairy and subtle, and mortals are not supposed to really look at it. It's been tweaked to some pretty extreme degrees, because it ends up being involved any time you look up a filename. I still remember how happy I was to merge the new lockless RCU filename lookup code last year.
At the opposite end of the spectrum, I actually wish more people understood the really core low-level kind of coding. Not big, complex stuff like the lockless name lookup, but simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev)
prev->next = entry->next;
else
list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
So there's lots of pride in doing the small details right. It may not be big and important code, but I do like seeing code where people really thought about the details, and clearly also were thinking about the compiler being able to generate efficient code (rather than hoping that the compiler is so smart that it can make efficient code *despite* the state of the original source code).
Books, Books, Books
by eldavojohn
As a software developer, I have a coveted collection of books. A few of said tomes -- both fiction and non -- have fundamentally altered the course of my life. Assuming yours aren't just man pages and .txt files, what are they?
Linus: I read a fair amount, but I have to admit that for me reading tends to be about escapism, and books to me are mostly forgettable. I can't really think of a single case of a book that struck me as life-changing, the way some people apparently find some book that really changed the way they think.
That said, I'll point to a couple of books I really enjoyed. On the non-fiction side, Richard Dawkin's "The Selfish Gene" was one book that I think is pretty influential. On the fiction side, as a teenager I enjoyed Heinlein's "Stranger in a strange land" a lot, and I have to admit to "Lord of the Rings" having been pretty important to me - but for a slightly odd reason, not as a huge Tolkien fan. For me, it was one of the first "real" books I read in English, and I started with a dictionary by my side, and ended it reading without needing one.
These days, I still read crap. I like my Kindle, and often read the self-published stuff for 99c. There are some real stinkers in there, but there's been a lot of "that was certainly worth the 99c" stuff too. I've also enjoyed just re-reading some of the classics I grew up with - I just re-read both the Count of Monte Cristo and the Three Musketeers, for example.
How do you deal with burn-out?
by kallisti5
You must of been burned out on Linux kernel development multiple-times over by now... how do you deal with it?
Linus: Oh, I really enjoy what I do. And I actually enjoy arguing too, and while I may swear a lot and appear like a grumpy angry old man at times, I am also pretty good at just letting things go. So I can be very passionate about some things, but at the same time I don't tend to really hold on to some particular issue for too long, and I think that helps avoid burn-out.
Obsessing about things is important, and things really do matter, but if you can't let go of them, you'll end up crazy.
So to me, some of the occasional flame-wars are really just invigorating. And the technology and the use cases end up changing enough that things never get *boring*, so I actually have not been close to burning out very often.
The one really painful time was some time during the middle of the 2.4.x series (about ten years ago), before I got to hand it over to stable maintenance, and we really had a lot of problems going on. You can google for "Linus doesn't scale" and various other threads about the problems we had back then, and it really was pretty painful. The kernel was growing and I wasn't keeping up, and BitKeeper and some fairly painful process changes really ended up helping a lot.
Describe your computer
by twistedcubic
Can you describe in detail your home and work computers, including processor, motherboard, and graphics card? And also say something about their compatibility with Linux?
Linus: My home computer isn't actually all that interesting: I don't need all that much CPU power any more, and for the last several years, my primary requirement (since CPU's are fast enough) has been that the system be really really quiet, and that it has a good SSD in it. If our cat deigns to jump into my lap while I'm working, the loudest noise in the room should be the purring of the cat, not the computer.
So my main desktop is actually a 4-core Westmere machine, not really anything special. The most unusual part of the machine is probably just the fact that it has a good case (I forget the exact case name now) which avoids rattling etc. And one of the bigger Intel SSD's. I think I'll be upgrading some time this fall, but I will have had that machine for two years now, I think.
My laptop (that I'm writing this with, since I'm traveling in Japan and Korea right now) is an 11" Apple Macbook Air from last year (but running Linux, of course - no OS X anywhere), because I really hate big laptops. I can't understand people who lug around 15" (or 17"!) monsters. The right weight for a laptop is 1kg, no more.
Re:The End
by Narnie
Speaking of ends, one day you'll pass on your duties. How do you envision the kernel and the Linux ecosystem after passing your reigns?
Linus: Oh, the kernel really has a very solid development community, I wouldn't worry about it. We've got several "top lieutenants" that could take over, and I'd worry much more about many other open-source projects that don't have nearly the same kind of big development community that the kernel does.
That said, I've been doing this for over twenty years now, and I don't really see myself stopping. I still do like what I'm doing, and I'd just be bored out of my gourd without the kernel to hack on.
tl;dr
Rhymes with nothing?
...someone I could sit down over a pint with and just geek out. Cool.
Operation Guillotine is in effect.
http://linux.slashdot.org/comments.pl?sid=3170757&cid=41589193
I the post above, user "hairyfeet (841228)" asks about stable ABI...
Sad that he did not answer to that question, or it was not chosen? I would have liked to hear some new arguments, and about future plans...
The questons he got, or choose to answer are not really deep, anyone could have given them...
Good to see Linus keeps up with his traditions in the first answer already by calling certain people morons. :-)
New things are always on the horizon
So why have you picked up the incredibly annoying habit of beginning half of your sentences with a pointless two-letter word?
== Jez ==
Do you miss Firefox? Try Pale Moon.
He may be a genius and all, but sure is boring as hell. I'm glad he isn't a teacher. I can't see mysef staying awake for 15 minutes during his lecture.
simply good use of pointers-to-pointers etc. For example, I've seen too many people who delete a singly-linked list entry by keeping track of the "prev" entry, and then to delete the entry, doing something like
if (prev)
prev->next = entry->next;
else
list_head = entry->next;
and whenever I see code like that, I just go "This person doesn't understand pointers". And it's sadly quite common.
People who understand pointers just use a "pointer to the entry pointer", and initialize that with the address of the list_head. And then as they traverse the list, they can remove the entry without using any conditionals, by just doing a "*pp = entry->next".
I'm going to have to disgree with Linus on that one. When I'm coding in a mixed group of people that includes old farts and interns and the performance isn't that critical, I'll do the former over the latter to insure that everyone in the group will understand it easily and will have less chance of breaking it if they change it. It can mean the difference between code that is robust and code that is fragile when it's being worked on, not just when it's running.
Thanks, Linus, for taking the time to sit down and write up some in-depth, thoughtful answers. I, for one, enjoyed the answer regarding CPU design.
He loves to point out (correctly) that the internet is full of morons, but he does seem narrowly focused on CS. I was hoping his reading list would be more enlightening. I was looking for some philosophers (other than Dawkins) or even math. Math, because it's close to my heart and I could respect it. Philosophy because it is my heart, and genuinely broadens my world view. Like that Socrates quote: "the unquestioned life is hardly worth living."
I reject the Dawkins mention on the grounds that Linus is already known to be an atheist. It's like a christian telling you they read the bible.
PS: I don't reply to ACs.
Hey Linus, guess what's my favorite kernel to run on that NAS computer? Yours. And yes, it is an "actual computer." Sorry if it's not sexy enough for ya.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is the internet, not TV, so we can say fuck and crap and shit etc when we want to.
In the very least saying f*ck and cr*p and sh*t is disingenuous as you are trying to hide that you are actually saying fuck and crap and shit, yet everyone knows that is exactly what you are saying.
So either say it, or if you think the words are unpalatable then think of some other words to use in their place.
I am Slashdot. Are you Slashdot as well?
I found this part insightful beyond technology:
If you have "one overriding idea," you've made that idea the part of your thinking that serves as your reality-check, not reality itself as your reality-check. Great point, Linus, and one that I constantly encounter in completely non-tech-related fields.
While cool, they seems to be the source of a whole lot of security and stability issues...
This bit by Linus is easily one of the best and most concise quotes about problem-solving that I've read. Any sot of 'manifesto' about programming or engineering in general that does not have a caveat along these lines as one of its tenets is extremely flawed.
"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."
1. Because I felt like it. :-)
2. Because I felt like it.
3. Because I felt like it.
4. Because I felt like it.
5. Because I felt like it.
Table-ized A.I.
Wait a minute...
The answer is not 42. Wtf?
Mastering the English language is fucking easy: all you have to do is to put an f* word in every fucking sentence.
Always good to see another Slashvertisement for the Apple MacBook Air. Very subtle this time.
"Greg is "special""
C|N>K
I personally disliked a couple of pointed things he said. The first was spindle bashing. Its not that I dislike SSDs per se, but I've run a heap of them over an extended term. My take on them is they have got much faster, but their lifespan has shortened. SSD death is far too common for my liking. And the size and value of HDD over SSD remains what it was. For me, bluntly SSD has not matched what was written on the tin, and I am really really disliking the early death in use. Its almost become perverse to a point where if I have to run IO heavy stuff, and I know its going to have a long life, I am not using SSD unless speed is a paramount primary concern. And in that case I have to spec for short burn lifespan. No, I can't take his view that one tech holds a definitive superiority over the other. Not so far at any rate.
And the thin and light blurb. No Linus, I actually happen to like a big screen. And I like dual drives, a DVD drive/Blue ray, and decent speakers. Add in a real GPU and chunky CPU and RAM mean I have a real actual PC worth a shit. The worst fucking thing ever to happen to PCs - and I really mean this, the worst thing to ever happen has been the netbook and now the garbage ultrabook cretinous stupidity. These are all either horribly hobbled, or massively over priced piles of steaming garbage. Usually vaguely the spec of the previous gen 'business' notebook in the case of ultrabooks, thrown in a thinner chassis, with a mild refresh, and crippled thermals and perfornance.
If I want a fairly crippled system - I can go get one based on an ARM platform that is in actual fact thinner. And its better on battery if thats all you care about. I'm not against thin and light. Those models have always been around, and frankly always had a premium price tag. But if this is to become the platform that is the PC, its deservedly dead man walking, and good riddance.
*Sales of netbooks and Ultrabooks speak in more volume on this matter than my spiel.
Trying to play to a strength you do not possess isn't listed in an book of clever plays. And dropping your areas where you have strength for them is a baffling outcome.
I'll add one last thing. For both the PC and for Linux - currently it sits at the end of a cycle in 'gaming; culture where the PC is at a zenith. There is no more powerful gaming platform today than PC. But it has to actually be powerful. The PC could regererate in short order into a full blown game platform, but its not going to do that on ultrabook, netbook or garbage books. And its sat right now at the potential bottom of the curve, because PS3 and XBox are landing at the bottom of their curve, and you can see this clearly in game development circles. If all the vendors simply ship ultrabooks, then they deserve to die. (and they are, PC shipments are falling.)
Make stuff people want, and you need a reason for it to be bought. Simply being shit like your last PC but thinner is as shit a reason as there has ever been.
We`re all equal
I think what he meant to say was:
*pp = (*pp)->next
Right?
So many of the answers took the form, "that use doesn't fit my personal needs, so people who have those needs are crazy/uncool/idiots." It's very good that Linux is now in a position to ensure quality code, not decide on what code will be included.
He also needs to do a bit more refactoring on
if he thinks there's a non-fragile way to implement such a system. Or, even better, do a git and find the primitives that would allow such a system - nobody else in history has managed to do so, but that only makes the odds of success highly unlikely, not necessarily impossible.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
So there's been a few small details that I think we could have done better, but on the whole I'm *very* happy with git. I think the core design is very solid, and we have almost zero redundant information, and the core model is really built around a few solid concepts that make a lot of sense.
I had hoped to see that answered with "I wish I had started git as libgit+git from the get-go, instead of the hacky shell-script semi-architecture it started with" - but that's (obviously) because I value portability and embeddability in other projects.
Also, while I appreciate Linus' outspoken no-bullshit personality, I find that sometimes it devolves into cursing and rudeness - this is one of the occasions where he's entirely mellow, lucid and reasonable, and that's nice to see :-)
Coffee-driven development.
I enjoyed the read. Many quotables afaic. Concise and to the point answering , tongue in cheeck where possible , ego centered , but not egotistical , and how could you do any different ?
Avoid your fears , or wonder at the past
Truthfully, he came across kind of crotchety. Not impressed.
Did you not read the responses to that question?
Linux runs on over two dozen processor architectures. Things that aren't integrated with the kernel don't have a prayer of working on different systems.
But okay, this isn't a huge issue, just the kernel's ability to talk to hardware. People are writing all sorts of drivers for Solaris, Mac OSX, and BSD, because they have stable ABIs. Heck, I like to write one of each a day -- before breakfast, if possible.
A stable ABI is a tradeoff: guaranteed compatibility for the short term, and guaranteed incompatibility for the long term. Eventually the OS vendor will change their driver interfaces, and unless the affected drivers are in the kernel, someone else is going to have to take some extra effort to fix them and distribute their changes.
Also, I'd like to introduce you to the concept of technical debt: The cost of maintaining bad code -- e.g., keeping around an obsolete API/ABI for compatibility's sake -- tends to accrue over time. In the context of the previous paragraph, Microsoft pushes this technical debt off to device manufacturers, with interest.
Lastly, in addition to the technical reasons, Linus likes the non-stable ABI and the GPL because they both force more code to be contributed back to the kernel. That's your soundbite answer. You're probably not going to make headway on this issue.
I leave the floor open to anyone who has tried and failed to get driver code into the kernel: i.e. those with a legitimate complaint.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
That said, I've been doing this for over twenty years now, and I don't really see myself stopping. I still do like what I'm doing, and I'd just be bored out of my gourd without the kernel to hack on.
And this is why he changed the world. Doing what he loves, even if Linux is not his favorite child.
Dawkins has a lot to say about God. Much of it very funny. That's not what The Selfish Gene is about.
The Selfish Gene is to Evolutionary Theory what A Brief History of Time is to... Time.
In a way accessible to normal humans, he exposes the process of genetic selection in that makes evolution an unavoidable conclusion from simple (fairly inarguable) biological principals.
I don't recall it making any direct references to diety. Though if you have list of things that you don't think could happen without the help of a diety, you may have to cross one line off it.
Same video as above, but clickable.
A pirate I was meant to be
I think perhaps the point that he was making about designing with pointers wasn't fully appreciated by everyone, because he didn't really spell it out. It's not just a matter of preferred coding style nor clarity, far from it.
The unconditional pointer update approach is atomic by virtue of the update being performed in a single memory write cycle, whereas the longer conditional form is clearly not atomic, and to make it atomic would require using locks. (There's a bit more to it than that because you still have to worry about what is being assigned, but it does reduce the scope of the problem significantly.)
This distinction is extremely important in a highly concurrent application like an operating system kernel, because you can merrily use his preferred code everywhere without worrying whether it's going to be used concurrently or only called within a protected critical region. In contrast, if the conditional form were used concurrently then you would have a wonderful recipe for intermittent concurrency bugs, the kernel designer's very worst nightmare.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
That or someone saw "orange/door hinge" on Disney's One Saturday Morning.
Try reading a literal translation of the Hebrew Scriptures, such as the English Standard Version or the New World Translation, and count how many sentences begin with an adverb or conjunction. If it's good enough for God, it's good enough for Linus.
Programs come installed on RAM bearing cartridges. Need more memory to save your photoshop files? well, you should have bought the Pro version with a larger SSD.
Even with the cartridge model as seen on video game consoles, you still need pointers to store more than one document.
Not enough RAM to render your CAD drawing? Too bad you didn't by the Enterprise Extended Edition, it came with 32Gb of RAM and a faster GPU.
Now you're getting into the pre-PS1 arcade model, where each game came on a custom PCB. (Later arcade platforms, such as System 573 or Triforce or Taito Type X, used essentially PC or console hardware.)
OK, how about "fsck you"? It has the connotations of both "fuck you" and "your thoughts appear to need checked for inconsistencies".
And the thin and light blurb. No Linus, I actually happen to like a big screen.
You're entitled to your preference, but some people happen to like a computer that fits in the bag they already have, like my 10" Dell laptop.
And I like dual drives, a DVD drive/Blue ray, and decent speakers.
All of which I have hanging off a USB hub at home. One plug, and I have a mouse, keypad (for Blender, which works acceptably on a GMA 3100), CF/SD writer, and a fourth port to connect either an external hard drive or a tablet. I don't need these peripherals while riding the bus to and from work.
If I want a fairly crippled system - I can go get one based on an ARM platform
The advantage of x86 is that it runs the non-free applications you already have. Look at the license of Linux: it's not the GPLv2 alone but the GPLv2 with an explicit exception (or clarification) to allow the use of non-free applications. "NOTE! This copyright does not cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does not fall under the heading of 'derived work'."
Finally, there's no real need for a gaming platform more powerful than consoles any more. What is needed now is for the console manufacturers to embrace modding
Once a console adds support for user-made game mods, it ceases to be a console and becomes a personal computer because in theory, a sufficiently powerful means of modding allows general computation using the game as an I/O framework. Mods would compete with major-label games, and the major labels can't have that.
or for some company which already supports those things to make a console.
Microsoft made the Windows operating system, which supports every feature you mentioned. Then it went and made a console, intentionally dropping those features.
Really, what you are talking about is putting a PC in the living room for games.
I agree with this concept of HTPC gaming, and I've agreed for a long time. It's just naysayers like CronoCloud who disagree.
Something Valve has recently made a lot easier, BTW.
The verb tense confuses me. Did the Steambox already come out in select markets? If not, where should one buy a ready-to-use gaming PC that doesn't look and sound (fan noise) out of place next to a 32" or larger living-room monitor?
so you aren't interested in any console on the market right now?
Wii, Xbox 360, and PS3 don't require online activation for single-player or single-screen multiplayer modes of disc games. Nor do they require tens of GB of download traffic per month to install disc games. It is expected, based on the user experience of Steam for PCs, that the Steambox will require both. And no, I'm not interested in these consoles due to the lack of deep modding support. The closest the Wii and DS ever got to a game designed to be thoroughly modded was WarioWare DIY, and after the rejection of Bob's Game, WarioWare DIY is the last Nintendo product I'll buy for a while.
So, you claim that organized efforts to ensure that religious dogma stays out of science classes, or to find ways to avoid the demonization that atheism receives in many communities and societies around the world, would constitute "ritual and tradition for nothing"? I contest the "ritual", the "tradition", and the "for nothing" in that statement.
Let's start with tradition, as that's probably the easiest for you to claim. Here's the thing: unlike (organized) religions, where one is more-or-less expected to carry out certain actions (go to church, pray toward Mecca, celebrate some holidays, whatever), there is absolutely no expectation that athiests go to athiest conferences. Nor is there a "tradition" of athiests, as a community, even holding such conferences. Pilgrimage is considered a tradition in some religions, even if many people never take one, because it's seen as a thing that "people in that religion do". Aside from in the context of this discussion, though, I've never heard of "go to athiest conferences" as a thing that atheists do (and I've been athiest, or at least agnostic, for over 80% of my life; I knew that I didn't believe in a deity before I knew there was a word for it).
Moving on, consider the claim that it's a "ritual" to hold or attend such concerences. I suspect this is your own unfamiliarity with the thought process of people who reject the very notion of "take it on faith", here. Ritual implies something practiced, something repeated, a sequence of actions that people have learned to do for the sake of the ritual itself. That's not to say that there's anything wrong with the actions of a ritual, just that, if you're trying to build on things, to understand them and improve them, it isn't a ritual at all. With most devout Christians, for example, going to church is a ritual; they may know why they do it, but they don't try to analyze the behavior. For a good preacher, writing and delivering a sermon should be absolutely not a ritual; he or she should be trying to guide people, to convince them of something or dissuade them from an action, to speak to the congregation in terms that they will understand, or at least that they think they understand. That's a matter of thought and creativity and understanding. By contrast, at an athiest conference, those things are expected of everybody. People host conferences because they want to bring others who are interested in a topic together. People attend conferences because they want to talk about, or listen to, what others have to say on a topic. Both the hosts and the attendees have their own ideas to share, their own questions to ask. Nobody is going through rote actions. Everybody has thought about it and made a conscious decision to attend, rather than simply carrying out some practice that is ingrained in them. It's the opposite of a ritual.
Finally, let's consider the claim that these things which a tiny handful of atheists sometimes do, are done "for nothing." It is a simple fact of history that religions tend to be supporessive of radical ideas. The very concept of "heresy" is an impediment to human progress. It is one thing to disprove a hypothesis, or even discredit a publication which makes fraudulent claims. It is quite another to denounce a line of thought purely on the basis of what one was taught. Allowing religious beliefs to be taught in schools, or to guide public policies, acts contrary to the core concept of science, and therefore to human advancement: that ideas (theories, in the common usage) must be testable, demonstrable, and refutable, before they can be accepted as the basis for new theories. What's more, the old theories are never considered to simple facts; they are always open to refutation by alternative theories that explain observations better. The idea that religion, with its dogma and concept of heresy, can guide the lives and actions of people, either in the individual or as a society, is perhaps the greatest single man-made retardant to the advancement of human knowledge. For those who take an active i
There's no place I could be, since I've found Serenity...
to quote nikola Tesla — "If Edison had a needle to find in a haystack,
he would proceed at once with the diligence of the bee to examine
straw after straw until he found the object of his search.
I was a sorry witness of such doings, knowing that a little theory
and calculation would have saved him ninety per cent of his labour.
(Nikola Tesla, New York Times, October 19, 1931)
likewise msr torvalds — you advocate stable processors — elegance be damned.
true enough, stability is paramount for reliability — but it is also important to
not preserve a perverse or arcane standard.
knowing what features to consolidate and prune can save a great deal of useless
backwards compatibility work, and save labour down the road.
two examples: i) we could do well to learn from the feat of the late s.jobs — where he
was able to poll the developers about what APIs they were actually using — and
prune out a bunch of dead CRUFT, and leave a core set of stable APIs (the now
defunct CARBON) that would bridge developers — by tweaking a little code,
they could gain the benefit of the new OSX architecture, while maintaining
backwards compatibility. ii) the move from parallel printer, and PS2 style
keyboard and mouse vs the move to USB — it was wise to eliminate multiple
incompatible standards which were being used in wrong ways (parallel printer
ports being used for ZIP drives!?!?) — total USB and elimination of legacy ports
was a good call.
instead of MONOLITHIC & CRUFTY — lean and well-defined.
please.
2cents from toronto island
jp
Can someone explain or point to an example that he's talking about in his response to the favorite hack question? I'm no pointer newbie, and I get pointer to pointers, but I've never seen an example use what he describes. I'm really just more curious to see how a pro does it.. Thanks
I nominate yours as the best sig of all this thread.
********* sig: If you don't like the law, get filthy stinking rich, and buy a better one.
Thanks for sharing, I will bookmark and be back again.
Asp.net Application development
Game consoles are already general purpose computers, by definition. They may well have a locked-down interface, but that is not the same thing. They are entirely capable of executing arbitrary code
I thought a "general-purpose computer" was something that could act as the universal linear bounded automaton.* We appear to be running into a definition clash. Mandatory code signing, the requirement that a third party has blessed a particular input to the ULBA, makes the input not "arbitrary" as I understand the definition of "arbitrary". Or has the concept of code signing been introduced into the universal Turing machine framework such that "arbitrary" can be germanely redefined?
* The ULBA is the physically realizable subset of the universal Turing machine.
Ironically ...a Mauritian company registered officially his name "LINUX SOLUTIONS LTD" further more claimed to detain copyright on GNU/GPL Licensed Asterisk VoIP in a Sworn Affidavit in Mauritius Supreme Court ...and that the License does not apply to them !!!
Berne Convention blatantly breached !! and I wonder How Mr Linus Torvalds would fight this his own copyright breached ???
Athesim is the word for believing in non-existence of any deity. There are religions without any deity therefore atheism doesn't mean having no religion. The word for not believing in (unprovable) existence of deities is agnosticism.
Who is called upon proving something has nothing to do with the meaning of words. Explaining wrong things quite well also doesn't change the falsehood.
Did the Steambox already come out in select markets? If not, where should one buy a ready-to-use gaming PC that doesn't look and sound (fan noise) out of place next to a 32" or larger living-room monitor?
No, they created a TV Mode [called Big Picture]
The page you linked links to a setup page, which states: "Step 1: Carry your PC or Mac to your HDTV." I don't think a lot of people are going to want to carry the family PC back and forth. So let me rephrase my second question in light of this: if someone is buying a new Windows PC to use with Steam Big Picture, what models do you recommend that have "low-noise, small size, good USB connectivity, on-board WiFi, and a decent case design" and the 512 MB DirectX 10 graphics card that Big Picture recommends?
Thank you. Linus, all developers on various projects, from my Country South Africa, Canonical's Mark Shuttleworth "The First African in Space" and of course the linux users out there..... Greetings from sunna South Africa. HBOT
Ps. Thanx SlashDot
Sure, maybe those rotating platters are ok in some NAS box that you keep your big media files on (or in that cloud storage cluster you use, and where the network latencies make the disk latencies be secondary), but in an actual computer? Ugh. "Get thee behind me, Satan".
So, Linus, what exactly do you think that NAS box and the cloud storage cluster are running? The pathetic state of storage management in Linux is the single biggest issue I have with it. Run ZFS systems for a while, enjoy the integration of devices, volumes, and filesystems.. Then go look at MD/LVM and the limits of ext4 and it's sad, really sad, enough that I'm reluctantly using HBA RAID instead. I lose the ability to mirror across HBA's for fault tolerance, but at least operations don't take a zillion fiddly steps.
I don't like his comment on DCBZ
No, I want out-of-order and "high-level" instructions that actually work across different implementations of the same ISA, and across different classes of hardware (iow, span the whole "low-power embedded" to "high-end server" CPU range). So for example, I think having a "memcpy" or "memset" instruction is a great idea, if it allows you to have something that works optimally for different memory subsystems and microarchitectures.
As an example of what not to do, is to expose direct cacheline access with some idiotic "DCBZ" instruction that clears them - because that will then make the software have to care about the size of the cacheline etc. Same goes for things like "nontemporal accesses" that bypass the L1 cache - how do you know when to use those in software when different CPU's have different cache subsystems? Software just shouldn't care. Software wants to clear memory, not aligned cachelines, and software does not want to have to worry about how to do that most efficiently on some particular new machine with a particular cache size and memory subsystem.
DCBZ is described here
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.aixassem/doc/alangref/dcbz.htm
If you look at a memset on a traditional CPU you're actually wasting time writing zeros individually to each location on a cache line. That works, but what you really mean at the start of a line is not
"Pull the cache line in from main memory if necessary, perhaps evicting a line containing something else. I'm writing a zero to the first location, second location ... last line". This means you read the line from memory and then fill it full of zeros. It will then sit in the cache dirty until it gets written back. Reading it into the cache means something else got kicked out.
What you really mean is
"I'd like to clobber the whole cache line with zeros". I.e. whether or not you have it, just fill it with zeros and mark it dirty. Or, better, write zeros to it bypassing the cache completely - that way you don't pollute the cache."
dcbz is a way to say that.
They explain it here
http://www.ibm.com/developerworks/power/library/pa-memory/index.html
It just means you need to write some PPC specific code for memset. Which IBM give you. If you do it it will run faster. If you do it the old way it will still work.
I.e. it's an architecture specific optimisation. I think he's saying that it would better to make the old way as fast as dcbz. I'm not sure that's possible - the CPU can't turn a bunch of stores into the equivalent of dcbzs. It's one of those situations where the old way is slow because you're not giving the CPU enough information about what you really mean.
If you've got an embedded system that's slow it's worth profiling it. If there architectural things like this that aren't being used in the hot spot functions its worth implementing them.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I REALLY enjoyed reading all these answers.. and i firmly believe that you could learn more about software coding just reading this post than anywhere else in a day, even though he doesn't really cover the subject at all, but just by the way of looking at things, the way he does.. (like his preference for efficiency, to name one point). He has a really well ordered brain, IMHO.. Just my 2cents worth, here.. ;-)
Except this code is only atomic on certain CPU architectures with certain compiler flags enabled. Now picture a million instances of that "atomic" code running in a couple thousand threads simultaneously. On one machine it works, on another you'll get random crashes everywhere. That's why a mutex lock or similar should always be employed if portability is a concern. Once you have to start fixing your code by changing those million locations where you forgot to use a mutex, you'll see why it is a bad idea.
Hi, I would like to ask how to encourage people to realize Linux and open source in the country that can easily get illegal software for cheap. Most of the comment that they make on Linux are "linux is good, but it is difficult to use or difficult to find someone to maintain, and I can get software for cheap (illegal). Or "Linux is free, how I can trust" . I have been provide Linux solutions > 10 years, still have to answer these comments. I am wondering you may have some suggestions.
Thank you,
PP
I presume it works with OpenSolaris, FreeBSD, Mac OS, and/or iOS.
You have an unsupported leap in logic there: that drivers don't exist because there isn't a stable ABI.
Also, do show me the binary driver that works across two dozen cpu architectures. Or the manufacturer who is willing to release two dozen drivers for a niche platform.
In other words, show that the lack of a stable ABI caused this problem, and then show that it would be a better solution. And don't ignore embedded linux; it's more profitable than the desktop.
P.S. What resources have you contributed towards solving this problem?
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
I'm a little disappointed that the creator/god of the linux kernel uses a Mac laptop with linux on it. Thats kind of a slap in the face to him. You buy a Mac to use the Mac OS considering they only support certain hardware to their liking and the stability and performance that comes with it. Linux can go on several different hardware platforms so there is no point to prove there. And since Apple switched to Intel platform you can get a similar PC laptop with same hardware specs a hell of a lot cheaper. Putting Linux on a Mac laptop will never meet the performance and stability that Mac OS would have. Just kinda ignorant to pay $1500 to $2000 on a laptop that most people use for the OS itself instead of paying $600 to 800 for the same setup from another vendor to throw linux on it.
Linus might not understand the need to lug about a "monster"- the thing is twofold for me and his needs aren't mine...
- Smaller than 17" displays have entirely too low a dot-pitch and are too small for my aging type II diabetic eyes. I can limp along with a 15" display, but...
- Most of those "smaller" machines don't have the muscle needed to dev work, etc. and since I consult, doing things like porting game code, etc...
Lesser machines don't do what I need. I don't really need a laptop in the normal sense (If I'm doing traditional laptop-ish things, my Android tablet does nicely enough and weighs in less than even his Macbook...)- I need a portable, reasonably lightweight desktop replacement. But then, Linus isn't doing what I'm doing- it probably makes sense for him there.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas