They're not. Microsoft has a monopoly. They can tell anyone to get lost.
No, they can only tell people to get lost until they eventually go too far and force people to use one of the many other reasonable computing platform options. See, MS isn't really a monopoly. You DO have other options. They may not have all the bells and whistles, but they exist. It's really a matter of what you're willing to give up in order to get away from Microsoft. Eventually the trade off will become WORTH IT.
I don't know what 8 year old code you think would still compile against todays Linux. Between major changes from the pre 2.0 kernel days to now I can think of plenty of code that would break.
I'd say just about everything from 8 years ago would compile just fine against a modern system. Do you actually write any code? Most vanilla UNIX apps, and by that I mean apps which don't interface with strange devices or talk USB or manipulate the filesystem or something like that, are written in accordance with POSIX standards (or ideally they should be). Not only do they compile fine on modern Linux systems, they compile fine on modern UNIX that isn't even Linux. And that's how it should be.
I work on a medium sized (500,000+ lines) commercial product which runs on UNIX and Windows. I've been doing it for 7 years. We have NEVER encountered problems with changing Linux environments, or at least, nothing that could not be fixed by a simple recompile. And the EXACT same code runs on our Solaris build, our HP-UX build, our AIX build, etc etc. The UNIX API is set in stone. Linux tacks new things on from time to time. We rightfully ignore those things, as should anybody with any care whatsoever for portability.
Did you know that the silly "./configure" script that comes with most GPL software is essentially pointless? There's really not much that needs to be configured, at least if you have the slightest skill in writing portable code. Whenever I see a configure script for a 5000-line COMMAND LINE APP, I laugh heartily to myself for a few minutes...
I think you definitely need to include a Speak'n'Spell in there. Great little computer with a VOICE SYNTHESIZER with a price low enough to make it a reasonable gift for your kids. I remember being amazed by it. I also remember getting a smack from my mother for making it say certain things...
Yeah, because the whole point of this article was the number of cores, nothing to do with oh say, PHOTONIC processing of signals or anything like that.
A link isn't a copy of the information it links to. A link is instructions for where to find someone else's server that is willing to give you the information. Outlawing links is like outlawing giving directions.
No, it's not quite that simple. Things like frames make it easy to be deceptive with links. Let's toss out everything we know about physics for a second and consider this scenario:
Suppose I have a brick and mortar store. Because I am an alien who has total control over spacetime, I am able to embed the spacetime of a local Walmart inside my own store. When a customer walks into my store, they see Walmart and cheerfully do their shopping there. But in order to get in/out of Walmart, they have to go through MY STORE. This gives me the opportunity to sell things to them. And my store will have WAY more customers coming through (because of the Walmart) than it would have had otherwise. Basically, I am capitalizing on the success of Walmart because I am able to "embed" a Walmart into my own store.
Linking external content deceptively into a frame on your own website is pretty much the same thing. People are lead to that site by the content (which isn't mine), and even though their primary interest is in the other person's content, they are still AT MY SITE and I can still benefit financially from that.
Having said all this, I do not like this judge's ruling.
I have no idea where you get "known to work fine on a reasonably modern single-core system" from. How did you possibly determine that? How did you reach that conclusion?
Why, you're absolutely right. There is no proof that video players work. I've never seen a computer play video, nor have I ever met a person who has. Point conceded.
In this day and age where anybody can wardrive past your place and do God knows what with your Internet connection (provided your WAP isn't secured), how can simple Google query logs prove ANYTHING? For all we know, this guy had an enemy at work who decided to set him up.
And if he doesn't have a WAP, or it's secured, then it's just as possible that the aforementioned enemy somehow hacked into this guy's computer and sent those queries.
How likely is this to happen? Maybe not that likely, but in this country at least guilt must be proved BEYOND reasonable doubt. I think the ease with which people can compromise your home net connection definitely provides reasonable doubt. In ALL cases.
Even more, the fact that this guy is clearly not "liked" at work just makes it even more plausible that somebody would want to frame him. What are the chances? Low, probably, but is there reasonable doubt? Definitely.
There is no magic codec that requires X CPU time. As you change the resolution, bitrate, and encoding options, CPU requirements change dramatically.
Yes, but you can typically say with certainly whether a particular codec will be able to run with reasonable parameters on a single core or not. Can you do realtime decoding of 1080i video on a Pentium 300? Probably not, who cares.
That isn't even remotely close to the question asked.
Riiiight. Let's go back to the original post:
Do you know of any video player that will be capable of taking advantage of two processors? As far as I know mplayer doesn't, xine doesn't and vlc doesn't.
Let's see... He asks about multicore codecs... Examples of which include three common codecs, all of which are known to work fine on a reasonably modern single-core system. How is this not equivalent to what I said?
Uh, no. One would expect that people working on decoder software that requires multiple CPUs to run in realtime would probably develop it... for multiple CPUs. Not really the case the OP was talking about I think. The question was, why no multicore codecs for common video formats?
You're worried that if someone steals your laptop, they might be able to find your email address and spam you?
First of all, I said email PASSWORD, not address. Somebody could steal my laptop and read my email and send email from my account. That would require them to be able to discern the password in all the millions of bytes of swap data, but I can imagine writing a program that could scan for candidates.
If my email password happened to be equal to my main account password (as can happen due to certain policies, but thankfully not in this case), that's quite a bit more serious. It makes me wonder what else might be lurking in the swap partition. When you type a password (like say, the root password for your main file server) into an application, you're really placing all your faith in that application to dispose of that data appropriately. So yeah, I'd be worried, especially in the context of a company, where it's easy to get your hands on a laptop that doesn't belong to you.
It's probably NEVER a good idea to keep sensitive data in the clipboard. You never know when that particular chunk of memory might get swapped out to disk. When that happens, your "secure" data is now sitting in plaintext form inside your swap file. Secure data really needs to be handled only by secure applications (with appropriate memory pins to prevent sensitive data from going out to an unencrypted volume). The clipboard is definitely not something I'd consider for that purpose.
I've grepped for my email password in my swap file before. It was there. Not good.
Interesting you mention it. My wife works at a very large maker of computer parts (which will remain unnamed). They regularly have to send several terabytes of technical data between a site in Oregon and one in California. They have a FAT PIPE to do this with, but they discovered that the servers on either end of the pipe aren't fast enough (sending OR receiving) to saturate the pipe.
So my wife's task was to construct a program which reads the data in parallel from their massively parallel filesystems, compresses it and sends it via hundreds of "little servers," and it is received by hundreds of other "little servers" on the other side and integrated back together. This is literally the only way that they can saturate the pipe. A cool project really, and a hard one to solve reliably due to race conditions, general unreliability when you have that many machines interacting, etc.
Point is though, it's really damn hard to fill a pipe that wide, and practically impossible for a home user with a computer that can, at best, only crank out a measly gigabit per second or so.
Yeah, it seems like a silly way to do it. Why not just put a power sensor on the main ground pin for the CPU (or do they have multiple ground pins?) and measure the power draw of the CPU directly? Come on, these are overclockers and hardware hacker geeks, surely they can do something simple like that.
Concerning the more serious first part of your post, it seems that ideally what you want to do is dedicate one CPU/core to interactive tasks, and another core for batch tasks. That way, the interactive tasks can easily interrupt each other as often as necessary on one CPU, while the other CPU cranks along on the batch tasks with a much longer time quantum without any unnecessary interruptions.
Do you know of any video player that will be capable of taking advantage of two processors?
Kind of a funny question. The only reason a person would ask is if a single processor in their machine was too slow to play a video on its own. I've never heard of that. Otherwise, what's the point in using both processors to decode video? Only one processor is required, and the other processor of your SMP system will take care of any other processes that need to run. Splitting a task that requires less than 100% CPU between multiple CPUs is silly.
Imagine a task where you have to drag a 3 ton boulder, and you have two pickup trucks. Either truck is capable of hauling the rock on its own, but for some reason you decide to tie BOTH trucks to the boulder. Okay... Maybe there's less "strain" on the engines in that case, but why do it that way when you can drag the boulder with ONE truck and have the other truck completely available for some other purpose?
Shotgunning four drinks one after the other (binging, basically) is one thing. Drinking four drinks over the course of a six hour evening is something else. I'm kind of surprised at the number as well. Wikipedia's page on cirrhosis states that "There is great variability in the amount of alcohol needed to cause cirrhosis (as little as 3-4 drinks a day in some men and 2-3 in some women)." This seems to put 3-4 drinks as a LOWER bound on the danger zone. There may be people (quite a few people in fact) who can tolerate more than that.
For me it is purely a matter of convenience. Because of my experience with C, I have all the implicit type conversion rules built into my head, and I take advantage of them all the time. For a beginner in C, these rules can make it seem impossible to predict exactly what operation will actually occur. As an example consider the expression 1.0f + 5 - 'a' -- what types do the temporary expressions have, what is the ultimate type of the final expression, in what order to type promotions occur, etc? To me it is apparent, to someone inexperienced it is a mystery. I don't deny that coding in C and actually enjoying it is quickly becoming old-school and even a little crusty.
Just to clarify the parent's comment, DYNAMIC/STATIC refers to the ability or inability of an lvalue to change its type during the course of execution. STRONG/WEAK refers to restrictions the compiler places on which kind of operations can be applied to which types. The two concepts are pretty much orthogonal.
In C, for instance, typing is static because a variable is declared as a specific type and that type cannot change. The typing is also WEAK because the C compiler does not impose very many restrictions on operations between types -- you can assign an unsigned char to an int with no complaints, or cast a pointer into another type of pointer, or pass an integer to a function which expects a float (and the compiler will automatically do the type conversion).
The disadvantage of a dynamically typed language is that you cannot know, without using reflection mechanisms, what type an lvalue actually contains. The disadvantage to weakly typed languages is that you cannot easily know which implicit type conversions the compiler is performing. But working in a statically, strongly typed language can feel very constraining and idiomatic. I think C strikes a fairly reasonable compromise. JavaScript on the other hand confuses the hell out of me.
I hope you're not breaking your NDA by telling everyone that. If you are, enjoy your cement shoes.
I don't understand this mystical quality people want to attach to Google. It's nothing more than a really kickass place to work (from what I saw). It's not like they're cracking Nazi codes in there. If you want certain things to be secrets, you don't build your building primarily out of glass with a totally open floor plan, and write every random thought anybody has on whiteboards all over the place. If anything, secrecy is exactly what Google does NOT want, at least internally.
A friend who works at Google took me on a tour of a few of their buildings a little over a year ago. It was the weekend and hardly anybody was there, but I did remember noticing a big whiteboard (Google has thousands of whiteboards, which seem to be the primary medium for communication and development of ideas) with the headline "Google And NASA in 2007" at the top. I remember thinking at the time how odd that seemed. But it looks like out of all the zany ideas at Google this was one that actually survived for over a year and came to fruition.
don't you want low thermal conductivity (e.g. aerogel)? You want to insulate the surface from your heat, not conduct it to the surface (that was the GP's point)
I chose steel because it's a very poor choice. If even a very poor choice is okay, then a GOOD choice is even better, no?
Heck you could use some sort of aerogel... if you have the technology to put giant beams of 'carbon steel' on Titan, you should be able to come up with a high strength aerogel.
I chose carbon steel because it has a relatively high thermal conductivity, so it would be hard to argue against the numbers. Yeah, obviously steel is not the sort of material you want to be bringing to Titan.
Also, since Titan has a surface gravity about 1/7th that of Earth, any supports you use won't have to be nearly as large as they would be on Earth -- and therefore wouldn't conduct as much heat.
Mars is probably a smarter choice, but it would not be IMPOSSIBLE to set up a colony on Titan, at least not because of the heat issue.
No metals would work, nor even concrete. So what were you suggesting, or hadn't you thought it through?
Let's say carbon steel, with a thermal conductivity of 54 watts per meter-kelvin. Imagine a carbon steel stilt, 10 cm in radius (20 cm diameter), and 5 meters tall. In reality, a stilt would probably be hollow or I-beam shaped (a solid bar 20 cm across is way overkill), so this calculation OVERESTIMATES the conducted power. Assume the temperature difference between the top and bottom of the stilt is 200 kelvins (94 K for surface of Titan, ~300 K for room temperature). Plug it in:
k = P*H/(A*DT) where P is the conducted power, H is the height, DT is the temperature difference, A is cross sectional area of the stilt. Solve for the conducted power:
P = k*A*DT/H. We have values k=54 W/m*K, A=2*Pi*0.1^2 meters, DT=200 kelvins, H=5 meters. What do we get? Conducted power is 135 watts. On this damn stilt only 135 watts will leak out of the bottom. So hey, let's calculate power density using a few other reasonable values.
Assume the stilt is buried 1 meter beneath the surface. So we have a total buried surface area of 1 meter * 2*pi*0.1 meters = 0.63 square meters, or 6300 square centimeters. So the power density is only 135 watts / 6300 cm^2 = ONLY 21.4 milliwatts per square centimeter.
Now, this is all very encouraging already, but hey! Why not do the proper engineering thing and actually INSULATE the stilts at the points where they connect to the living structure. Now the heat transfer to the ground we have to worry about will be FAR, FAR less than even a wimpy 21.4 milliwatts per cm^2.
Oh and hey! We've forgotten about the heat which is lost when it radiates away from the stilt. This calculation doesn't even ATTEMPT to figure that in. And that effect would serve to even FURTHER reduce the thermal power being conducted to the ground.
Basically, you have no idea what the hell you're speculating on.
Humans are natural, hence they are part of natural selection. This false dichotomy between nature and man is, frankly, just so much hippie bullshit.
Absolutely true. However, this kind of thing makes me sad. No, it doesn't make the universe sad -- it makes me sad. Why would I want to preserve a species that's going extinct? Not because I think the world will hate me if I don't. It's because *I* think we should reduce the scale of our environmental impacts. Dolphins are cool. So I want them to continue to exist.
I'm quite sure that "nature" wouldn't care if we blew the whole damn world up. But it sure would suck for *us*, wouldn't it?
Slashdot Mirror
They're not. Microsoft has a monopoly. They can tell anyone to get lost.
No, they can only tell people to get lost until they eventually go too far and force people to use one of the many other reasonable computing platform options. See, MS isn't really a monopoly. You DO have other options. They may not have all the bells and whistles, but they exist. It's really a matter of what you're willing to give up in order to get away from Microsoft. Eventually the trade off will become WORTH IT.
I don't know what 8 year old code you think would still compile against todays Linux. Between major changes from the pre 2.0 kernel days to now I can think of plenty of code that would break.
I'd say just about everything from 8 years ago would compile just fine against a modern system. Do you actually write any code? Most vanilla UNIX apps, and by that I mean apps which don't interface with strange devices or talk USB or manipulate the filesystem or something like that, are written in accordance with POSIX standards (or ideally they should be). Not only do they compile fine on modern Linux systems, they compile fine on modern UNIX that isn't even Linux. And that's how it should be.
I work on a medium sized (500,000+ lines) commercial product which runs on UNIX and Windows. I've been doing it for 7 years. We have NEVER encountered problems with changing Linux environments, or at least, nothing that could not be fixed by a simple recompile. And the EXACT same code runs on our Solaris build, our HP-UX build, our AIX build, etc etc. The UNIX API is set in stone. Linux tacks new things on from time to time. We rightfully ignore those things, as should anybody with any care whatsoever for portability.
Did you know that the silly "./configure" script that comes with most GPL software is essentially pointless? There's really not much that needs to be configured, at least if you have the slightest skill in writing portable code. Whenever I see a configure script for a 5000-line COMMAND LINE APP, I laugh heartily to myself for a few minutes...
Can you please close that opening parenthesis? I think I just blew my stack.
I think you definitely need to include a Speak'n'Spell in there. Great little computer with a VOICE SYNTHESIZER with a price low enough to make it a reasonable gift for your kids. I remember being amazed by it. I also remember getting a smack from my mother for making it say certain things...
Yeah, because the whole point of this article was the number of cores, nothing to do with oh say, PHOTONIC processing of signals or anything like that.
To your comment I say: Ho hum.
A link isn't a copy of the information it links to. A link is instructions for where to find someone else's server that is willing to give you the information. Outlawing links is like outlawing giving directions.
No, it's not quite that simple. Things like frames make it easy to be deceptive with links. Let's toss out everything we know about physics for a second and consider this scenario:
Suppose I have a brick and mortar store. Because I am an alien who has total control over spacetime, I am able to embed the spacetime of a local Walmart inside my own store. When a customer walks into my store, they see Walmart and cheerfully do their shopping there. But in order to get in/out of Walmart, they have to go through MY STORE. This gives me the opportunity to sell things to them. And my store will have WAY more customers coming through (because of the Walmart) than it would have had otherwise. Basically, I am capitalizing on the success of Walmart because I am able to "embed" a Walmart into my own store.
Linking external content deceptively into a frame on your own website is pretty much the same thing. People are lead to that site by the content (which isn't mine), and even though their primary interest is in the other person's content, they are still AT MY SITE and I can still benefit financially from that.
Having said all this, I do not like this judge's ruling.
I have no idea where you get "known to work fine on a reasonably modern single-core system" from. How did you possibly determine that? How did you reach that conclusion?
Why, you're absolutely right. There is no proof that video players work. I've never seen a computer play video, nor have I ever met a person who has. Point conceded.
In this day and age where anybody can wardrive past your place and do God knows what with your Internet connection (provided your WAP isn't secured), how can simple Google query logs prove ANYTHING? For all we know, this guy had an enemy at work who decided to set him up.
And if he doesn't have a WAP, or it's secured, then it's just as possible that the aforementioned enemy somehow hacked into this guy's computer and sent those queries.
How likely is this to happen? Maybe not that likely, but in this country at least guilt must be proved BEYOND reasonable doubt. I think the ease with which people can compromise your home net connection definitely provides reasonable doubt. In ALL cases.
Even more, the fact that this guy is clearly not "liked" at work just makes it even more plausible that somebody would want to frame him. What are the chances? Low, probably, but is there reasonable doubt? Definitely.
There is no magic codec that requires X CPU time. As you change the resolution, bitrate, and encoding options, CPU requirements change dramatically.
Yes, but you can typically say with certainly whether a particular codec will be able to run with reasonable parameters on a single core or not. Can you do realtime decoding of 1080i video on a Pentium 300? Probably not, who cares.
That isn't even remotely close to the question asked.
Riiiight. Let's go back to the original post:
Do you know of any video player that will be capable of taking advantage of two processors? As far as I know mplayer doesn't, xine doesn't and vlc doesn't.
Let's see... He asks about multicore codecs... Examples of which include three common codecs, all of which are known to work fine on a reasonably modern single-core system. How is this not equivalent to what I said?
Your entire post is therefore moot.
Uh, no. One would expect that people working on decoder software that requires multiple CPUs to run in realtime would probably develop it... for multiple CPUs. Not really the case the OP was talking about I think. The question was, why no multicore codecs for common video formats?
You're worried that if someone steals your laptop, they might be able to find your email address and spam you?
First of all, I said email PASSWORD, not address. Somebody could steal my laptop and read my email and send email from my account. That would require them to be able to discern the password in all the millions of bytes of swap data, but I can imagine writing a program that could scan for candidates.
If my email password happened to be equal to my main account password (as can happen due to certain policies, but thankfully not in this case), that's quite a bit more serious. It makes me wonder what else might be lurking in the swap partition. When you type a password (like say, the root password for your main file server) into an application, you're really placing all your faith in that application to dispose of that data appropriately. So yeah, I'd be worried, especially in the context of a company, where it's easy to get your hands on a laptop that doesn't belong to you.
It's probably NEVER a good idea to keep sensitive data in the clipboard. You never know when that particular chunk of memory might get swapped out to disk. When that happens, your "secure" data is now sitting in plaintext form inside your swap file. Secure data really needs to be handled only by secure applications (with appropriate memory pins to prevent sensitive data from going out to an unencrypted volume). The clipboard is definitely not something I'd consider for that purpose.
I've grepped for my email password in my swap file before. It was there. Not good.
Interesting you mention it. My wife works at a very large maker of computer parts (which will remain unnamed). They regularly have to send several terabytes of technical data between a site in Oregon and one in California. They have a FAT PIPE to do this with, but they discovered that the servers on either end of the pipe aren't fast enough (sending OR receiving) to saturate the pipe.
So my wife's task was to construct a program which reads the data in parallel from their massively parallel filesystems, compresses it and sends it via hundreds of "little servers," and it is received by hundreds of other "little servers" on the other side and integrated back together. This is literally the only way that they can saturate the pipe. A cool project really, and a hard one to solve reliably due to race conditions, general unreliability when you have that many machines interacting, etc.
Point is though, it's really damn hard to fill a pipe that wide, and practically impossible for a home user with a computer that can, at best, only crank out a measly gigabit per second or so.
Yeah, it seems like a silly way to do it. Why not just put a power sensor on the main ground pin for the CPU (or do they have multiple ground pins?) and measure the power draw of the CPU directly? Come on, these are overclockers and hardware hacker geeks, surely they can do something simple like that.
Concerning the more serious first part of your post, it seems that ideally what you want to do is dedicate one CPU/core to interactive tasks, and another core for batch tasks. That way, the interactive tasks can easily interrupt each other as often as necessary on one CPU, while the other CPU cranks along on the batch tasks with a much longer time quantum without any unnecessary interruptions.
Do you know of any video player that will be capable of taking advantage of two processors?
Kind of a funny question. The only reason a person would ask is if a single processor in their machine was too slow to play a video on its own. I've never heard of that. Otherwise, what's the point in using both processors to decode video? Only one processor is required, and the other processor of your SMP system will take care of any other processes that need to run. Splitting a task that requires less than 100% CPU between multiple CPUs is silly.
Imagine a task where you have to drag a 3 ton boulder, and you have two pickup trucks. Either truck is capable of hauling the rock on its own, but for some reason you decide to tie BOTH trucks to the boulder. Okay... Maybe there's less "strain" on the engines in that case, but why do it that way when you can drag the boulder with ONE truck and have the other truck completely available for some other purpose?
Shotgunning four drinks one after the other (binging, basically) is one thing. Drinking four drinks over the course of a six hour evening is something else. I'm kind of surprised at the number as well. Wikipedia's page on cirrhosis states that "There is great variability in the amount of alcohol needed to cause cirrhosis (as little as 3-4 drinks a day in some men and 2-3 in some women)." This seems to put 3-4 drinks as a LOWER bound on the danger zone. There may be people (quite a few people in fact) who can tolerate more than that.
For me it is purely a matter of convenience. Because of my experience with C, I have all the implicit type conversion rules built into my head, and I take advantage of them all the time. For a beginner in C, these rules can make it seem impossible to predict exactly what operation will actually occur. As an example consider the expression 1.0f + 5 - 'a' -- what types do the temporary expressions have, what is the ultimate type of the final expression, in what order to type promotions occur, etc? To me it is apparent, to someone inexperienced it is a mystery. I don't deny that coding in C and actually enjoying it is quickly becoming old-school and even a little crusty.
Just to clarify the parent's comment, DYNAMIC/STATIC refers to the ability or inability of an lvalue to change its type during the course of execution. STRONG/WEAK refers to restrictions the compiler places on which kind of operations can be applied to which types. The two concepts are pretty much orthogonal.
In C, for instance, typing is static because a variable is declared as a specific type and that type cannot change. The typing is also WEAK because the C compiler does not impose very many restrictions on operations between types -- you can assign an unsigned char to an int with no complaints, or cast a pointer into another type of pointer, or pass an integer to a function which expects a float (and the compiler will automatically do the type conversion).
The disadvantage of a dynamically typed language is that you cannot know, without using reflection mechanisms, what type an lvalue actually contains. The disadvantage to weakly typed languages is that you cannot easily know which implicit type conversions the compiler is performing. But working in a statically, strongly typed language can feel very constraining and idiomatic. I think C strikes a fairly reasonable compromise. JavaScript on the other hand confuses the hell out of me.
I hope you're not breaking your NDA by telling everyone that. If you are, enjoy your cement shoes.
I don't understand this mystical quality people want to attach to Google. It's nothing more than a really kickass place to work (from what I saw). It's not like they're cracking Nazi codes in there. If you want certain things to be secrets, you don't build your building primarily out of glass with a totally open floor plan, and write every random thought anybody has on whiteboards all over the place. If anything, secrecy is exactly what Google does NOT want, at least internally.
A friend who works at Google took me on a tour of a few of their buildings a little over a year ago. It was the weekend and hardly anybody was there, but I did remember noticing a big whiteboard (Google has thousands of whiteboards, which seem to be the primary medium for communication and development of ideas) with the headline "Google And NASA in 2007" at the top. I remember thinking at the time how odd that seemed. But it looks like out of all the zany ideas at Google this was one that actually survived for over a year and came to fruition.
don't you want low thermal conductivity (e.g. aerogel)? You want to insulate the surface from your heat, not conduct it to the surface (that was the GP's point)
I chose steel because it's a very poor choice. If even a very poor choice is okay, then a GOOD choice is even better, no?
Heck you could use some sort of aerogel... if you have the technology to put giant beams of 'carbon steel' on Titan, you should be able to come up with a high strength aerogel.
I chose carbon steel because it has a relatively high thermal conductivity, so it would be hard to argue against the numbers. Yeah, obviously steel is not the sort of material you want to be bringing to Titan.
Also, since Titan has a surface gravity about 1/7th that of Earth, any supports you use won't have to be nearly as large as they would be on Earth -- and therefore wouldn't conduct as much heat.
Mars is probably a smarter choice, but it would not be IMPOSSIBLE to set up a colony on Titan, at least not because of the heat issue.
No metals would work, nor even concrete. So what were you suggesting, or hadn't you thought it through?
Let's say carbon steel, with a thermal conductivity of 54 watts per meter-kelvin. Imagine a carbon steel stilt, 10 cm in radius (20 cm diameter), and 5 meters tall. In reality, a stilt would probably be hollow or I-beam shaped (a solid bar 20 cm across is way overkill), so this calculation OVERESTIMATES the conducted power. Assume the temperature difference between the top and bottom of the stilt is 200 kelvins (94 K for surface of Titan, ~300 K for room temperature). Plug it in:
k = P*H/(A*DT) where P is the conducted power, H is the height, DT is the temperature difference, A is cross sectional area of the stilt. Solve for the conducted power:
P = k*A*DT/H. We have values k=54 W/m*K, A=2*Pi*0.1^2 meters, DT=200 kelvins, H=5 meters. What do we get? Conducted power is 135 watts. On this damn stilt only 135 watts will leak out of the bottom. So hey, let's calculate power density using a few other reasonable values.
Assume the stilt is buried 1 meter beneath the surface. So we have a total buried surface area of 1 meter * 2*pi*0.1 meters = 0.63 square meters, or 6300 square centimeters. So the power density is only 135 watts / 6300 cm^2 = ONLY 21.4 milliwatts per square centimeter.
Now, this is all very encouraging already, but hey! Why not do the proper engineering thing and actually INSULATE the stilts at the points where they connect to the living structure. Now the heat transfer to the ground we have to worry about will be FAR, FAR less than even a wimpy 21.4 milliwatts per cm^2.
Oh and hey! We've forgotten about the heat which is lost when it radiates away from the stilt. This calculation doesn't even ATTEMPT to figure that in. And that effect would serve to even FURTHER reduce the thermal power being conducted to the ground.
Basically, you have no idea what the hell you're speculating on.
Humans are natural, hence they are part of natural selection. This false dichotomy between nature and man is, frankly, just so much hippie bullshit.
Absolutely true. However, this kind of thing makes me sad. No, it doesn't make the universe sad -- it makes me sad. Why would I want to preserve a species that's going extinct? Not because I think the world will hate me if I don't. It's because *I* think we should reduce the scale of our environmental impacts. Dolphins are cool. So I want them to continue to exist.
I'm quite sure that "nature" wouldn't care if we blew the whole damn world up. But it sure would suck for *us*, wouldn't it?