Choice is always good. Aside from that, SpaceX' stuff is all entirely privately funded and designed themselves, and as such doesn't have the same kind of legal snarls that using governmental technology would have: it is, if you like, a clean room reimplementation of space technology. (They are the only space company to build their launch vehicles, in their own factory, from scratch --- engines, tankage, the lot.)
Also, the Dragon is likely to be (a) cheaper and (b) here on time, when compared to the ESA or Ares capsule (assuming the Ares capsule's not going to be cancelled). And Soyuz, despite being really nice technology, is politically a bit uncomfortable, so it's always worth having a backup.
Damn straight. Focusing on one language will cripple you. Learn as many languages as you can; you'll be a better programmer for it. Learning Smalltalk taught me about OO. Learning Forth taught me about code factoring and reuse. Learning assembly taught me C (and learning C taught me assembly). Learning Python taught me about the joys of good libraries, and learning Lua taught me how awesome a tiny, fast scripting language can be. And learning Haskell taught me how much I have still to learn.
There are a lot of *very cool* domain-specific languages out there, most of them written in the 80s and 90s --- not much has changed in the world of programming languages in the past decade! --- and they're well worth a look. Even if you never write any production code in any of them, they'll teach you huge amounts.
Yeah, they stole that from Occam, 25 years ago... SEQ i = 0 FOR 1000
doSomething()
PAR i = 0 FOR 1000
doSomething()
It was a good idea then, and it's still a good idea now, but C/C++ isn't really designed for this sort of thing --- Occam discourages global state, for example, and makes it very easy to have processes communicate via CSP (message passing) which means you very rarely need to use locks in Occam. As you say, most non-trivial uses of parallel_for() will still be a lot of work.
(Those who do not study the lessons that obsolete programming languages teach us are doomed to... er... C, I expect.)
I've never been able to get my head around writing idiomatic functional code, and that was despite being taught Haskell at university --- I know the language, I just can't do anything useful with it! I'm just too much of a procedural programmer, and that's something I regret.
I did try OCaml a little while back, reasoning that because it supports mutable state, it would be easier to learn. It was. I ended up writing procedural code in it, which rather defeated the whole point. It's a nice language, but I don't think it's suitable for learning functional style.
Haskell's the best option that I know of, but the syntax is rather weird to anyone who's used to languages like C or Java. Are there any other lazy, strict functional languages that aren't descended from the ML family that I should look at?
Shame there was not one in the shuttle - I seem to remember it was in the original proposal?
The first four flights had modified SR-71 ejection seats, but they'd only be useful in the last stages of descent, and were only there because they were test flights.
Escaping from dying spacecraft is rather harder than it looks. It's only in the first 45 seconds or so after launch when a rocket's going slowly enough to eject from. Challenger broke up about 70 seconds into flight, at which point it was already travelling at over a kilometre per second --- and the breakup wasn't caused by the explosion; it was caused by the explosion wrecking the shuttle's aerodynamics to such an extent that it started tumbling, and then the hypersonic wind tore the vehicle apart. You don't eject into that. Most fighter aircraft ejection seats can only be used at speeds of 300 metres per second or so (although I'm sure someone can quote me something really esoteric that works at faster speeds).
The shuttle does have an escape protocol; you put the vehicle into a stable glide and jump out the door (using a frankly ludicrous system to avoid hitting that huge wing). They put that in after the loss of Challenger. It wouldn't have helped.
The best way of escaping during launch is to fire the entire crew capsule free. Mercury, Apollo, Soyuz and the upcoming Orion, if it doesn't get cancelled, all used/will use escape towers; a set of solid fuel rockets on the crew capsule designed to get the capsule clear of an impending explosion in a hurry. But they're intended to work on the ground, and get ejected about 50 seconds into the flight.
You might be interested to read up about Soyuz 18a; the second stage hadn't separated when the third stage fired! The Soyuz capule was jettisoned, reentered normally, and landed safely. But that accident happened much later, when the whole vehicle was out of the atmosphere in a suborbital trajectory. Not having to worry about atmosphere makes things far easier.
Escaping on reentry is much harder. Columbia broke up while travelling at about *eight* kilometres per second, through atmosphere. I don't know of any way to survive an event like that.
With your too-large belly you have a higher risk at heart disease, but I guess you don't mind your insurance company finding out about it and charging you a higher fee...
But that's not a privacy problem. That's simply because you've decided to trade your health on the open market, by buying health insurance (which I assume is what you're talking about). The insurers are charging you a higher premium because you're a bigger risk because you're overweight --- in other words, the market is working as it's designed to.
Whether that is a problem or not is an entirely different and quite interesting question. But it's not a privacy-related problem.
You can get 16GB SDHC cards for about 30 USD. Those are class 6, which means you get anything from about 8MB/s to 20MB/s depending on the brand. Of course, if you want more speed, you can always use RAID0.
In fact, given how cheap they are, a RAID5 system would probably make sense. You get a speed boost, and the ability to hot swap a single card if it goes bad. ZFS would also work really well, but I don't know if you'd get a speed boost that way. Also, all these approaches would allow you to very easily extend your system by buying another card (and reader) and adding it to the pool. (You may want to check up on whether you can remove it again later, though.)
Hmm. Thanks for prompting me to go and look at this stuff. I might actually do this for my next lightweight server.
Javascripts vary in quality, but the latest ones are pretty fast: for example, Javascript V8 (the Javascript from Google's Chrome browser project) is nearly as fast as Lua, which is the fastest widely used scripting language at the moment.
You might be interested in my project Clue, which is fairly similar to the Adobe project --- it compiles ANSI C into dynamic programming languages. The current released version does Lua, Javascript and Perl5; the version in SVN also does C and has a half-finished Common Lisp backend as well (code generator is done, but the contributor didn't include a libc).
I'm seeing speeds of about 1/5 of native with LuaJIT. Javascript via V8 is a bit slower. Unaccelerated SpiderMonkey produces about 1/100, and Perl5 is appalling 1/500 of native. Unfortunately, most dynamic languages don't support GOTO, which given Clue's fairly naive code generation spoils performance. (The Javascript backend has to emit a big switch statement in a loop for every function to handle control flowing from one basic block to another.) The Lua back end does nasty bytecode patching tricks to make GOTO work, which I've had to take out of the SVN version because it was just too horrible. Eventually I need to implement some sort of basic block graph reforming system to try and reduce the number of GOTOs in the generated code, but it's a lot harder than it looks.
However, unlike Adobe, all this is running on stock, unmodified VMs --- instead of implementing lots of specialised VM opcodes to make things like byte memory accesses work, I'm bending the ANSI C standard as far as it'll go to make it fit the dynamic world rather better. It's all standards-compliant, but the coding environment is odd: sizeof(char) == sizeof(int) == sizeof(double) == 1; sizeof(void*) == 2. So if nothing else, it'll make a decent testing environment.
Any volunteers to do Parrot, Ruby, Python etc back ends? Better still, any compiler theory gurus who are interested in the basic block reforming code? Nah, thought not...
Since when is an increase of efficiency by 100% impossible?
Yeah, but that's not what the summary says. It says it's increasing the efficiency to 100%. Depending on what it's referring to this means that (a) it's extracting all the kinetic energy out of the air, which means air flows into the turbine but not out of it; or (b) it's extracting all the kinetic energy out of the drive shaft, which means the drive shaft stops. Either of these gives you hilarious results and division by zero errors.
TFA is much clearer, saying that the new generator can give up to 50% more power over the existing generators, which are 90% efficient in optimal conditions but much less efficient at other times. In other words, the 50% isn't applied to to the 90%. It is, I'm afraid a simple basic numeracy FAIL on the part of whoever compiled the summary.
That said, this does like a very neat gadget and will probably be useful in a lot of situations, such as regenerative braking on cars.
As long as the energy required to create the positrons is less than MC^2 (and I would imagine it would be) since anti-matter/matter has a approximate 100% mass to energy conversion, then there should be a net "gain".
Alas no. Antimatter is made from scratch, from pure energy. The laws of physics forbid the conversion of normal matter into antimatter. So not only do you have to feed in MC^2, you also have to do it in an incredibly inefficient way, because squeezing enough energy into a small enough space to 'condense' into matter is really, really hard.
Or they could have thrown the power budget out the window and used a nuclear-decay power source, like a lot of satellites do.
You might be interested to know that Spirit and Opportunity do have radioactive heaters --- eight each. These provide a certain amount of background heat.
However, the problem with these is that because they can't be turned off, you run into problems with the electronics getting too hot! So you always need to use undersized radioactive heaters and supplement them with electric heating.
Of course, as you say, using a proper RTG and big electric heaters would have dealt with the problem once and for all. Unfortunately it would also most likely have doubled the mass of the vehicles, along with the cost.
It's really not meant to be flamebait--I'm tired of war games that show war as this epic struggle that only involves soldiers vs soldiers destroying each other with cool toys. You never have to make tough moral decisions--you either shoot him or he shoots you.
Yeah, I agree. (Go read Only You Can Save Mankind by Terry Pratchett --- a kid is playing Space Invaders, when suddenly, they surrender. Then what?)
One of the few interesting things about the Left Behind game of a few years ago was that every character had a (different, IIRC) backstory, and that bodies didn't go away. Although the game itself was rather forgettable, I always thought that was a rather good idea, as a way of getting the player more involved with the characters, rather than just treating them as interchangeable, expendable blobs.
Bizarrely, I don't use it either --- and I do know about it. My internal network's on 10.0.0.0/8, too, which means I can use 10.1, 10.2 etc to refer to my machines.
I probably need more coffee. Or possibly less coffee.
I'm not sure this is valid --- it doesn't accept non-dotted IP addresses, does it? i.e. expressing 127.0.0.1 as 2130706433. (Or 127.1, but which is equally, and surprisingly, valid.)
Is that, some old assembly hackers ought to be able to whip up a fairly tiny basic interpreter. It should be fun in a way and still easier than in the old days of 6502.
A while back I wrote, more or less for a laugh, most of a Basic interpreter for the Infocom Z-Machine. It was seriously unfun, and I never finished it. And I was doing it in Inform, a relatively high-level language, too... the problem with Basic is that the syntax is friggin' bizarre, with all kinds of ghastly special cases and edge conditions. It's designed to be parsed as its interpreted, which means that all the various tokens change behaviour subtly depending on the statement they're embedded in. Consider ; vs , in INPUT and PRINT, for example, and once you've done that, think about ; vs , in INPUT# and PRINT#! And then you get on to the type rules... *shudder*
These days we're used to languages that are for more regular and easier to parse. Even C with its grammar from hell is at least regular. Even frigging Intercal has a more sensible grammar.
...now, there's an idea; an rommable Intercal interpreter for the C64. Finally, the right language for the machine!
Brace yourself; there were worse BASICs out there. For example, Sinclair BASIC, where the keyboard didn't even work properly, and you couldn't type in keywords --- instead it used complicated sequences of keyboard modifiers to map each keyword to a specific key. (Apparently they did it like that to avoid having to code a keyword tokeniser.) And even once you'd successfully found all the keywords, it still ran like suck; all floating point operations, for example, were done via interpreted bytecode, which really didn't help the speed.
At the other end of the spectrum (pun intended), Acorn's BBC Micro had the best popular BASIC pretty much ever; it was blazingly fast --- an order of magnitude faster than Spectrum BASIC, despite running on similar hardware --- and some decent structured programming support, such as named procedures with proper local variables. You could actually, genuinely, learn to program properly on BBC Basic, which you couldn't on Sinclair or Commodore BASIC. What's more, it even had a built-in assembler, which made it really simple to embed little fragments of machine code.
Let's see... it's been about 15 years since I did this stuff...
10 DIM code 100 : REM allocate 100 bytes for machine code 20 PROCassemble 30 REPEAT 40 CALL code 50 UNTIL FALSE 60 : 70 DEF PROCassemble 80 P% = code : REM assembly target address 90 FOR pass = 0 TO 2 STEP 2 : REM two pass assembly 90 [ OPT pass : REM start assembly 100 LDX #0 110.loop 120 LDA text, X 130 INX 140 JSR &FFEE : REM OSWRCH system call, writes a char 150 CMP #0 160 BNE loop 170 RTS 180.text 190 EQUS "Hello, world!" 200 EQUB 0 210 ] 220 NEXT 230 END PROC
Better still, go look through a junkyard for one of the old 6V hub dynamos --- those wheel rim generators have huge drag (and whine irritatingly). The hub dynamos are better in almost every way. They produce AC, so the easy option is to wire them up to a little transformer to produce 15V or so; rectify, smooth, regulate, and you should have something that can be fed directly to the average bit of electronics' charging circuit. The better option is to use a specialised switched-mode power supply to generate the required voltages. That'll be more efficient, and will produce the rock-solid 5V necessary for a powered USB socket, but you may not get any off-the-shelf parts to do it.
I have a T1000 and a T1000E. They're still really nice. Oh, sure, the actual computer inside sucks, but the general form factor, the awesome keyboard, the amazingly clear and easy-on-the-eyes screen, etc.
Unfortunately, the E's baby winchester (20MB, baby) suffers rather from stiction, and the floppy drives' rubber drive bands have both perished, which means I can't actually do anything with them. Shame; they'd make nice serial terminals.
Yeah. I'd really like to like OpenBSD. Technically, it's superb. It's smooth, polished, well documented --- it's got a level of consistency that most Linux distros can only hope to dream of. The kernel is well designed and fast, with excellent hardware support. System setup is consistent and well-thought out. Above all, it doesn't confuse easy-to-use with easy-to-learn --- everything is as simple as possible without oversimplifying, which makes it a joy to admin.
But then, every time I try to use it, I run up against the OpenBSD developers, who are an arrogant bunch of elitist assholes. In a couple of years, on and off, I think I've seen Theo make a civil reply to someone *once*. Maybe twice. No, I'm not kidding. When you see someone ask what looks to my untutored eye a reasonable question about VMs, and the head developer replies publicly with the words 'You are full of shit' and nothing else (apart from a complete copy of the original message, no snipping), there is something very wrong. Most of the other devs are nearly as bad, and of course there are hordes of groupies who assume that if the people in charge are okay with personal abuse, then it's alright for them, too.
Despite this, the actual operating system is definitely worth checking out if you're interested in what a well-designed Unix actually looks like. Linux can learn a lot from it.
Unfortunately you can't push anything bigger than microscopic with a laser. All that'll happen is they'll heat up. Given that this is a tankful of ammonia, that's probably not wise, because it'll either explode (producing lots of fragments in differing orbits) or burst (producing a directed thrust that'll radically change its orbit).
In general, it's much easier to get rid of stuff by sending it Earthwards than otherwise. If you're in low orbit, there's always some drag anyway --- that's why the ISS needs periodic boosting. It doesn't take much delta-vee to lower the orbit enough that drag increases sufficiently to make it burn up in short order. This only applies to low orbit, though: geostationary satellites can't be disposed of --- they simply don't carry enough fuel to send them anywhere near Earth. As the useful bits of the orbit are now getting rather cluttered with bits of junk, modern satellites tend to come with a specific end-of-life booster that shifts their orbits sufficiently that they won't be a traffic hazard. It doesn't take them very far, though.
Conversely, it takes huge amounts of delta-vee to send anything into an Earth escape trajectory: it's hard enough doing it with vehicles designed for the purpose, let alone remotely with bits of junk. It certainly doesn't happen by accident; you know all those bad movies where the villain ends up drifting away from the spaceship into the sun? If only it were that easy...
That's about twice as big as the Viking landers, which at 570kg are the biggest things to be landed on Mars to date.
They used an aeroshell for the initial reentry and to slow to 250m/s (are you allowed to call it a reentry if it's the first time you're entering the planet's atmosphere?), a set of parachutes to slow to 60m/s and to descend to 1.5km from the surface, and then rockets for the final touchdown, which happened at 2.5m/s.
However, I'd imagine that this approach would be totally unsuitable for a rover because you end up with lots of rocket hardware and tankage on the vehicle itself.
(Trivia: Viking 1 lasted for six years before someone accidentally overwrote the antenna pointing software. Viking 2's batteries failed after about half that time. Both landers were powered with a RCA1802 8-bit microprocessor. The whole project, both missions, cost about $1B in 1978, which is equivalent to about $4B in 2008 --- so the price of a trip to Mars is definitely coming down.)
After all, it is well known that the sunspot cycle and the economy are somehow linked. It's not the bankers' fault after all. Darn you, sun! Darn you to heck!
I'm still using it on Windows because I find it genuinely nicer than Firefox. AdBlock is the one feature I really miss; currently I use privoxy, but it's not nearly as easy to use. The main thing I like about Chrome is that the UI is so much cleaner than Firefox, and I'm not talking about the tabs; it's all the little things, like being able to find stuff in the preferences dialogue, to the focus model being much less stupidly modal which means it's easier to find where the caret's gone, etc.
The multithreaded model is nice, too; it feels far snappier than Firefox. I can't use the Firefox Awesomebar for searching, for example, because after the first few characters it hangs for about two seconds while it does a network lookup. Firefox is a right pig when it comes to multiple tabs, too, and as I frequently load about 20 at once I appreciate Chrome's smoothness. Oh, and I also like the way that when Quicktime crashes, it doesn't take my web browser with it.
I wish there was a proper adblocker for it, and I wish there was a Linux version; I'd switch in a moment...
Slashdot Mirror
Choice is always good. Aside from that, SpaceX' stuff is all entirely privately funded and designed themselves, and as such doesn't have the same kind of legal snarls that using governmental technology would have: it is, if you like, a clean room reimplementation of space technology. (They are the only space company to build their launch vehicles, in their own factory, from scratch --- engines, tankage, the lot.)
Also, the Dragon is likely to be (a) cheaper and (b) here on time, when compared to the ESA or Ares capsule (assuming the Ares capsule's not going to be cancelled). And Soyuz, despite being really nice technology, is politically a bit uncomfortable, so it's always worth having a backup.
Damn straight. Focusing on one language will cripple you. Learn as many languages as you can; you'll be a better programmer for it. Learning Smalltalk taught me about OO. Learning Forth taught me about code factoring and reuse. Learning assembly taught me C (and learning C taught me assembly). Learning Python taught me about the joys of good libraries, and learning Lua taught me how awesome a tiny, fast scripting language can be. And learning Haskell taught me how much I have still to learn.
There are a lot of *very cool* domain-specific languages out there, most of them written in the 80s and 90s --- not much has changed in the world of programming languages in the past decade! --- and they're well worth a look. Even if you never write any production code in any of them, they'll teach you huge amounts.
Yeah, they stole that from Occam, 25 years ago...
SEQ i = 0 FOR 1000
doSomething()
PAR i = 0 FOR 1000
doSomething()
It was a good idea then, and it's still a good idea now, but C/C++ isn't really designed for this sort of thing --- Occam discourages global state, for example, and makes it very easy to have processes communicate via CSP (message passing) which means you very rarely need to use locks in Occam. As you say, most non-trivial uses of parallel_for() will still be a lot of work.
(Those who do not study the lessons that obsolete programming languages teach us are doomed to... er... C, I expect.)
I've never been able to get my head around writing idiomatic functional code, and that was despite being taught Haskell at university --- I know the language, I just can't do anything useful with it! I'm just too much of a procedural programmer, and that's something I regret.
I did try OCaml a little while back, reasoning that because it supports mutable state, it would be easier to learn. It was. I ended up writing procedural code in it, which rather defeated the whole point. It's a nice language, but I don't think it's suitable for learning functional style.
Haskell's the best option that I know of, but the syntax is rather weird to anyone who's used to languages like C or Java. Are there any other lazy, strict functional languages that aren't descended from the ML family that I should look at?
The first four flights had modified SR-71 ejection seats, but they'd only be useful in the last stages of descent, and were only there because they were test flights.
Escaping from dying spacecraft is rather harder than it looks. It's only in the first 45 seconds or so after launch when a rocket's going slowly enough to eject from. Challenger broke up about 70 seconds into flight, at which point it was already travelling at over a kilometre per second --- and the breakup wasn't caused by the explosion; it was caused by the explosion wrecking the shuttle's aerodynamics to such an extent that it started tumbling, and then the hypersonic wind tore the vehicle apart. You don't eject into that. Most fighter aircraft ejection seats can only be used at speeds of 300 metres per second or so (although I'm sure someone can quote me something really esoteric that works at faster speeds).
The shuttle does have an escape protocol; you put the vehicle into a stable glide and jump out the door (using a frankly ludicrous system to avoid hitting that huge wing). They put that in after the loss of Challenger. It wouldn't have helped.
The best way of escaping during launch is to fire the entire crew capsule free. Mercury, Apollo, Soyuz and the upcoming Orion, if it doesn't get cancelled, all used/will use escape towers; a set of solid fuel rockets on the crew capsule designed to get the capsule clear of an impending explosion in a hurry. But they're intended to work on the ground, and get ejected about 50 seconds into the flight.
You might be interested to read up about Soyuz 18a; the second stage hadn't separated when the third stage fired! The Soyuz capule was jettisoned, reentered normally, and landed safely. But that accident happened much later, when the whole vehicle was out of the atmosphere in a suborbital trajectory. Not having to worry about atmosphere makes things far easier.
Escaping on reentry is much harder. Columbia broke up while travelling at about *eight* kilometres per second, through atmosphere. I don't know of any way to survive an event like that.
But that's not a privacy problem. That's simply because you've decided to trade your health on the open market, by buying health insurance (which I assume is what you're talking about). The insurers are charging you a higher premium because you're a bigger risk because you're overweight --- in other words, the market is working as it's designed to.
Whether that is a problem or not is an entirely different and quite interesting question. But it's not a privacy-related problem.
You can get 16GB SDHC cards for about 30 USD. Those are class 6, which means you get anything from about 8MB/s to 20MB/s depending on the brand. Of course, if you want more speed, you can always use RAID0.
In fact, given how cheap they are, a RAID5 system would probably make sense. You get a speed boost, and the ability to hot swap a single card if it goes bad. ZFS would also work really well, but I don't know if you'd get a speed boost that way. Also, all these approaches would allow you to very easily extend your system by buying another card (and reader) and adding it to the pool. (You may want to check up on whether you can remove it again later, though.)
Hmm. Thanks for prompting me to go and look at this stuff. I might actually do this for my next lightweight server.
You might be interested in my project Clue, which is fairly similar to the Adobe project --- it compiles ANSI C into dynamic programming languages. The current released version does Lua, Javascript and Perl5; the version in SVN also does C and has a half-finished Common Lisp backend as well (code generator is done, but the contributor didn't include a libc).
I'm seeing speeds of about 1/5 of native with LuaJIT. Javascript via V8 is a bit slower. Unaccelerated SpiderMonkey produces about 1/100, and Perl5 is appalling 1/500 of native. Unfortunately, most dynamic languages don't support GOTO, which given Clue's fairly naive code generation spoils performance. (The Javascript backend has to emit a big switch statement in a loop for every function to handle control flowing from one basic block to another.) The Lua back end does nasty bytecode patching tricks to make GOTO work, which I've had to take out of the SVN version because it was just too horrible. Eventually I need to implement some sort of basic block graph reforming system to try and reduce the number of GOTOs in the generated code, but it's a lot harder than it looks.
However, unlike Adobe, all this is running on stock, unmodified VMs --- instead of implementing lots of specialised VM opcodes to make things like byte memory accesses work, I'm bending the ANSI C standard as far as it'll go to make it fit the dynamic world rather better. It's all standards-compliant, but the coding environment is odd: sizeof(char) == sizeof(int) == sizeof(double) == 1; sizeof(void*) == 2. So if nothing else, it'll make a decent testing environment.
Any volunteers to do Parrot, Ruby, Python etc back ends? Better still, any compiler theory gurus who are interested in the basic block reforming code? Nah, thought not...
Yeah, but that's not what the summary says. It says it's increasing the efficiency to 100%. Depending on what it's referring to this means that (a) it's extracting all the kinetic energy out of the air, which means air flows into the turbine but not out of it; or (b) it's extracting all the kinetic energy out of the drive shaft, which means the drive shaft stops. Either of these gives you hilarious results and division by zero errors.
TFA is much clearer, saying that the new generator can give up to 50% more power over the existing generators, which are 90% efficient in optimal conditions but much less efficient at other times. In other words, the 50% isn't applied to to the 90%. It is, I'm afraid a simple basic numeracy FAIL on the part of whoever compiled the summary.
That said, this does like a very neat gadget and will probably be useful in a lot of situations, such as regenerative braking on cars.
Alas no. Antimatter is made from scratch, from pure energy. The laws of physics forbid the conversion of normal matter into antimatter. So not only do you have to feed in MC^2, you also have to do it in an incredibly inefficient way, because squeezing enough energy into a small enough space to 'condense' into matter is really, really hard.
No, of course Jesus wasn't original --- the whole concept is a blatant ripoff of Monty Python. Hey, it's on TV, it must be true...
Or they could have thrown the power budget out the window and used a nuclear-decay power source, like a lot of satellites do.
You might be interested to know that Spirit and Opportunity do have radioactive heaters --- eight each. These provide a certain amount of background heat.
However, the problem with these is that because they can't be turned off, you run into problems with the electronics getting too hot! So you always need to use undersized radioactive heaters and supplement them with electric heating.
Of course, as you say, using a proper RTG and big electric heaters would have dealt with the problem once and for all. Unfortunately it would also most likely have doubled the mass of the vehicles, along with the cost.
Well, it's not heavy metal, but this is a piece of music made entirely from the sounds of dying hard drives...
It's really not meant to be flamebait--I'm tired of war games that show war as this epic struggle that only involves soldiers vs soldiers destroying each other with cool toys. You never have to make tough moral decisions--you either shoot him or he shoots you.
Yeah, I agree. (Go read Only You Can Save Mankind by Terry Pratchett --- a kid is playing Space Invaders, when suddenly, they surrender. Then what?)
One of the few interesting things about the Left Behind game of a few years ago was that every character had a (different, IIRC) backstory, and that bodies didn't go away. Although the game itself was rather forgettable, I always thought that was a rather good idea, as a way of getting the player more involved with the characters, rather than just treating them as interchangeable, expendable blobs.
I probably need more coffee. Or possibly less coffee.
^((25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])\.){3}(25[0-5]|2[0-4][0-9]|1[0-9][0-9]|[1-9][0-9]|[0-9])$
I'm not sure this is valid --- it doesn't accept non-dotted IP addresses, does it? i.e. expressing 127.0.0.1 as 2130706433. (Or 127.1, but which is equally, and surprisingly, valid.)
Is that, some old assembly hackers ought to be able to whip up a fairly tiny basic interpreter. It should be fun in a way and still easier than in the old days of 6502.
A while back I wrote, more or less for a laugh, most of a Basic interpreter for the Infocom Z-Machine. It was seriously unfun, and I never finished it. And I was doing it in Inform, a relatively high-level language, too... the problem with Basic is that the syntax is friggin' bizarre, with all kinds of ghastly special cases and edge conditions. It's designed to be parsed as its interpreted, which means that all the various tokens change behaviour subtly depending on the statement they're embedded in. Consider ; vs , in INPUT and PRINT, for example, and once you've done that, think about ; vs , in INPUT# and PRINT#! And then you get on to the type rules... *shudder*
These days we're used to languages that are for more regular and easier to parse. Even C with its grammar from hell is at least regular. Even frigging Intercal has a more sensible grammar.
...now, there's an idea; an rommable Intercal interpreter for the C64. Finally, the right language for the machine!
Brace yourself; there were worse BASICs out there. For example, Sinclair BASIC, where the keyboard didn't even work properly, and you couldn't type in keywords --- instead it used complicated sequences of keyboard modifiers to map each keyword to a specific key. (Apparently they did it like that to avoid having to code a keyword tokeniser.) And even once you'd successfully found all the keywords, it still ran like suck; all floating point operations, for example, were done via interpreted bytecode, which really didn't help the speed.
At the other end of the spectrum (pun intended), Acorn's BBC Micro had the best popular BASIC pretty much ever; it was blazingly fast --- an order of magnitude faster than Spectrum BASIC, despite running on similar hardware --- and some decent structured programming support, such as named procedures with proper local variables. You could actually, genuinely, learn to program properly on BBC Basic, which you couldn't on Sinclair or Commodore BASIC. What's more, it even had a built-in assembler, which made it really simple to embed little fragments of machine code.
Let's see... it's been about 15 years since I did this stuff...
10 DIM code 100 : REM allocate 100 bytes for machine code .loop .text
20 PROCassemble
30 REPEAT
40 CALL code
50 UNTIL FALSE
60 :
70 DEF PROCassemble
80 P% = code : REM assembly target address
90 FOR pass = 0 TO 2 STEP 2 : REM two pass assembly
90 [ OPT pass : REM start assembly
100 LDX #0
110
120 LDA text, X
130 INX
140 JSR &FFEE : REM OSWRCH system call, writes a char
150 CMP #0
160 BNE loop
170 RTS
180
190 EQUS "Hello, world!"
200 EQUB 0
210 ]
220 NEXT
230 END PROC
Better still, go look through a junkyard for one of the old 6V hub dynamos --- those wheel rim generators have huge drag (and whine irritatingly). The hub dynamos are better in almost every way. They produce AC, so the easy option is to wire them up to a little transformer to produce 15V or so; rectify, smooth, regulate, and you should have something that can be fed directly to the average bit of electronics' charging circuit. The better option is to use a specialised switched-mode power supply to generate the required voltages. That'll be more efficient, and will produce the rock-solid 5V necessary for a powered USB socket, but you may not get any off-the-shelf parts to do it.
I have a T1000 and a T1000E. They're still really nice. Oh, sure, the actual computer inside sucks, but the general form factor, the awesome keyboard, the amazingly clear and easy-on-the-eyes screen, etc.
Unfortunately, the E's baby winchester (20MB, baby) suffers rather from stiction, and the floppy drives' rubber drive bands have both perished, which means I can't actually do anything with them. Shame; they'd make nice serial terminals.
Yeah. I'd really like to like OpenBSD. Technically, it's superb. It's smooth, polished, well documented --- it's got a level of consistency that most Linux distros can only hope to dream of. The kernel is well designed and fast, with excellent hardware support. System setup is consistent and well-thought out. Above all, it doesn't confuse easy-to-use with easy-to-learn --- everything is as simple as possible without oversimplifying, which makes it a joy to admin.
But then, every time I try to use it, I run up against the OpenBSD developers, who are an arrogant bunch of elitist assholes. In a couple of years, on and off, I think I've seen Theo make a civil reply to someone *once*. Maybe twice. No, I'm not kidding. When you see someone ask what looks to my untutored eye a reasonable question about VMs, and the head developer replies publicly with the words 'You are full of shit' and nothing else (apart from a complete copy of the original message, no snipping), there is something very wrong. Most of the other devs are nearly as bad, and of course there are hordes of groupies who assume that if the people in charge are okay with personal abuse, then it's alright for them, too.
Despite this, the actual operating system is definitely worth checking out if you're interested in what a well-designed Unix actually looks like. Linux can learn a lot from it.
Unfortunately you can't push anything bigger than microscopic with a laser. All that'll happen is they'll heat up. Given that this is a tankful of ammonia, that's probably not wise, because it'll either explode (producing lots of fragments in differing orbits) or burst (producing a directed thrust that'll radically change its orbit).
In general, it's much easier to get rid of stuff by sending it Earthwards than otherwise. If you're in low orbit, there's always some drag anyway --- that's why the ISS needs periodic boosting. It doesn't take much delta-vee to lower the orbit enough that drag increases sufficiently to make it burn up in short order. This only applies to low orbit, though: geostationary satellites can't be disposed of --- they simply don't carry enough fuel to send them anywhere near Earth. As the useful bits of the orbit are now getting rather cluttered with bits of junk, modern satellites tend to come with a specific end-of-life booster that shifts their orbits sufficiently that they won't be a traffic hazard. It doesn't take them very far, though.
Conversely, it takes huge amounts of delta-vee to send anything into an Earth escape trajectory: it's hard enough doing it with vehicles designed for the purpose, let alone remotely with bits of junk. It certainly doesn't happen by accident; you know all those bad movies where the villain ends up drifting away from the spaceship into the sun? If only it were that easy...
That's about twice as big as the Viking landers, which at 570kg are the biggest things to be landed on Mars to date.
They used an aeroshell for the initial reentry and to slow to 250m/s (are you allowed to call it a reentry if it's the first time you're entering the planet's atmosphere?), a set of parachutes to slow to 60m/s and to descend to 1.5km from the surface, and then rockets for the final touchdown, which happened at 2.5m/s.
However, I'd imagine that this approach would be totally unsuitable for a rover because you end up with lots of rocket hardware and tankage on the vehicle itself.
(Trivia: Viking 1 lasted for six years before someone accidentally overwrote the antenna pointing software. Viking 2's batteries failed after about half that time. Both landers were powered with a RCA1802 8-bit microprocessor. The whole project, both missions, cost about $1B in 1978, which is equivalent to about $4B in 2008 --- so the price of a trip to Mars is definitely coming down.)
After all, it is well known that the sunspot cycle and the economy are somehow linked. It's not the bankers' fault after all. Darn you, sun! Darn you to heck!
I'm still using it on Windows because I find it genuinely nicer than Firefox. AdBlock is the one feature I really miss; currently I use privoxy, but it's not nearly as easy to use. The main thing I like about Chrome is that the UI is so much cleaner than Firefox, and I'm not talking about the tabs; it's all the little things, like being able to find stuff in the preferences dialogue, to the focus model being much less stupidly modal which means it's easier to find where the caret's gone, etc.
The multithreaded model is nice, too; it feels far snappier than Firefox. I can't use the Firefox Awesomebar for searching, for example, because after the first few characters it hangs for about two seconds while it does a network lookup. Firefox is a right pig when it comes to multiple tabs, too, and as I frequently load about 20 at once I appreciate Chrome's smoothness. Oh, and I also like the way that when Quicktime crashes, it doesn't take my web browser with it.
I wish there was a proper adblocker for it, and I wish there was a Linux version; I'd switch in a moment...