1200mAh. 1.2V. OK, so P=VI and P=E/t, so E=VIt.
Thus the battery holds about 1.2 * 3600 * 1.2 = about 5KJoules.
90% charge efficient means 500Joules as heat.
E = c * m * delta_T
where c = specific heat capacity, m = mass, delta_T = temperature change.
According to Sony, a AA battery is 30g. I don't know what the specific heat capacity of a battery is, but metals are between 0.1 and 0.9, and water is 4. Lets assume it's 1.0 J/gK.
delta_T = E/c*m = 500/(1.0 * 30) = 16 celcius.
That's about 30F for those of you who like odd units. Not such a big deal.
That said, some olde tyme designs had three chains: one timing (to the cam), one primary (to the gearbox) and one final drive. But I have never seen a motorcycle cam or primary chain break through a case.
I had a primary drive chain fail on a old Honda 400 Four
under full throttle while banked over somewhat in a low-ish speed bend.
It didn't break through the case, but the engine sure stopped fast. The 10ms before I pulled in the clutch, and almost getting high-sided afterwards were one of those slow-motion moments I won't forget in a hurry. Fortunately no injuries other than a few pulled muscles from putting my foot down at 40mph.
I'm sure it would have been very interesting at a higher speed.
I'm a big advocate of free open source software, and I've written quite a lot myself. But you mustn't lose sight of the fact that it doesn't make sense for all software to be free. If there are enough people willing to put in effort to develop for free (or someone willing to fund it and still give it away - typically Universities fall in this category) then free distribution combined with free (to the users) development cost results in free software. And much of it is really good too - I'm typing this in Mozilla running on FreeBSD.
But some software is developed explicitly for one customer to give them an advantage over their competitors. If you want this software, you're going to have to make it worth the developers while.
Other software just isn't interesting to most developers. Anyone fancy developing a free version of TurboTax and updating it each year as the tax laws change? Didn't think so. If you want to use it you need to pay your fraction of the development costs, plus some.
Free software is great. But free distribution does not by itself result in free software.
Imagine if a constellation of THESE had been left to decay over the past 4 decades.
Well that would certainly have provided some incentive to develop a workable space-tug technology by now wouldn't it? (assuming there was anyone left alive to do so)
Having lived for a number of years in Boston, Berkeley, and London, I can tell you that the power is MUCH more reliable in London. Boston seemed to suffer from two or three outages a year, Berkeley more like seven or eight (three in the last two weeks), and London is about one outage every few years.
Now, whether it will stay that way with the lack of investment in England after electricity privatization, who can say.
This design also uses the wing itself as a massive air brake
This isn't quite correct. Here's a picture of SpaceShipOne feathered while descending.
The fuselage is more or less parallel to the ground, with the wings and tail trailing above/behind to provide stability. I believe the wings are not used as an air brake but rather the fuselage is.
This makes sense because it allows for a wing design that is much lighter than it would otherwise have to be, and hence they can make
the ship into a pretty good glider (unlike for example the space shuttle or X15) for the same take-off weight.
From the article:
It is possible to push the power consumption of the whole device ultimately to below 4 watts while still gaining a travel-TV sized color projection.
Well, a 15-inch LCD panel consumes about 30W, all in. I don't know how big a travel-TV is, but less say it's 7.5inches. Assuming power is proportional to area, then an LCD 7.5-inch travel TV would consume 7.5W. I assume some of that power is absorbed in the colour filters, and some more is lost in the polarizer, and some is used by the TFT itself. So it doesn't seem impossible to me to have a 7.5inch display that consumes 4W.
Of course this could still be vaporware, but I don't think the 4W number is a dead giveaway.
5. You are not required to accept this License, since you have not
signed it. However, nothing else grants you permission to modify or
distribute the Program or its derivative works. These actions are
prohibited by law if you do not accept this License. Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.
In stating that the GPL is invalid, they are refusing to accept it, and therefore do not have the right to distribute GPL'ed software.
The question is where would you submit such helpful gems? We really need something like bugzilla, but for help ("helpzilla"), where you can submit useful advice, and people can rank it according to how helpful it is.
Ideally later on someone would write some useful documentation based on the most helpful feedback.
To some extent, I think the open-source model could be made to work in our favour, if only the right tools were commonly available.
This is an interesting claim, because since patents are published, something can not be both patented and a trade secret.
This is not necessarily a contradiction. The CSS algorithm (or business model!) could be patented and published, and the player keys could still be a trade secret.
Allowing encrpyted communication with untrusted hosts is rather like meeting a stranger in a dark alley; whatever happens there won't be any witnesses.
No. Some of the momentum behind SIP was in part a reaction to H.323's uglyness, but the whole SIP effort actually started before H.323 was first finalized.
It definitely was not an evolution of H.323.
H.323 was really a mapping of H.320 ISDN videophones onto IP-based networks. The protocols are all binary.
SIP was designed from scratch for IP networks, and is a test-based protocol with HTTP-like syntax. SIP was also designed from the outset to perform user-location via a search. This makes it appropriate for scenarios where users move around between devices, and hence is good for A/V calls.
Microsoft and Intel opposed SIP from the start. But the telcos waded in, and it turns out they have more say than Microsoft for telephony-style stuff, and in the end Microsoft came to believe in SIP too.
Hmm, a good quality voice-grade codec uses perhaps 32Kbit/s. Less if you'd accept cellphone quality. Assume you recorded everything you hear when you're awake (say 16 hours/day). 300GB would fit 3.5 years of recording. I tend to assume upgrading disks every couple of years, and before then disks will have doubled in size again. So you could record everything you hear for the rest of your life, and keep it on a single disk.
Now whether you'd want to do this, and how you'd index the data in a useful manner are more difficult questions. As are backing the data up. But you could do this now if you wanted to. Food for thought.
After a smooth countdown and nominal engine ignition, the thirteen-foot long P-2 quickly accelerated up a 60-ft launch rail and entered stable flight. Several seconds later it abruptly pitched ninety degrees and demonstrated unstable operation until finally transitioning into a ballistic terminal descent. The subsequent impact with the desert floor destroyed student payloads provided by a USC/JPL team and another from Cerritos High School, but the aft section with the aerospike survived relatively intact. Preliminary analysis indicates that the most probable cause for the observed flight behavior is that part of the engine's graphite exit outer ring experienced excessive and asymmetric erosion, which in turn created a side thrust component.
I guess that's a form of success. But there's probably a reason why everyone else is still doing ground tests.
I control three domains that are currently registered with Versign/Network Solutions. Does anyone have good recommendations for alternative registrars that I can transfer these domains to?
You're quoting somewhat out of context. The next few lines read:
Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records.
For zones which do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone's permission.
We hesitate to recommend a flat prohibition against wildcards in "registry"-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users.
We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.
I can tell you that the IAB is not perfectly fine with this.
It's amazing what will get there, so long as the address is unique. I once addressed a postcard to:
username@sun.com
Sun Microsystems,
California, USA
I couldn't remember either how to spell my friend's surname, or her address, but could remember her email address. And it reached her in a couple of days.
But as for the reasons for not doing earth-orbit rendezvous - I don't think they hold anymore. Back when the plans for Apollo were drawn up, no-one had ever done orbital rendezvous. They were forced to do lunar-orbit rendezvous to make it work at all, but that was with manned spacecraft, so the computers didn't need to be so good. Earth orbit rendezvous missions required automatic docking, which hadn't been done at the time.
These days the Russion Progress supply craft do automatic docking with ISS (and with Mir before) on a regular basis, so that is all known technology. So long as you send the crew up in the re-entry vehicle last, then the risks going out are minimal. If you leave the re-entry vehicle in earth orbit, and you have a spare re-entry vehicle ready to launch just in case, then the risks coming back are relatively
low too.
In general, with modern computers to do the docking, I think it's much easier to design the software for orbital rendezvous and to use well-tested smaller rockets than it is to build and test the really big rockets you need to skip the earth-orbit rendezvous stage.
What makes you think they are going to take the same approach NASA did?
You need a Saturn-V or similar if you want to launch everything in one go. That minimizes risks, but it isn't the only way.
You could also launch the lunar lander, orbital transfer vehicle, and earth lander separately, and rendezvous in earth orbit. I think this would require something larger than a Soyuz launcher, but you could probably do it on something of the size of Ariane 5. Computers are a whole lot better than they were in the 60's, so orbital rendezvous is a lot less risky now than it was back then.
And if you're going to set up a lunar base, taking the Apollo approach makes no sense whatsoever - you want to reuse the orbital transfer vehicle, and as far as possible reuse the lunar lander. The only way to make all this work is to do earth orbit rendezvous.
If the US wanted to do it this way, the ISS would be a big help, but it isn't a requirement.
Slashdot Mirror
Thus the battery holds about 1.2 * 3600 * 1.2 = about 5KJoules.
90% charge efficient means 500Joules as heat.
E = c * m * delta_T
where c = specific heat capacity, m = mass, delta_T = temperature change.
According to Sony, a AA battery is 30g. I don't know what the specific heat capacity of a battery is, but metals are between 0.1 and 0.9, and water is 4. Lets assume it's 1.0 J/gK.
delta_T = E/c*m = 500/(1.0 * 30) = 16 celcius.
That's about 30F for those of you who like odd units. Not such a big deal.
Of course the 90% number is drawn out of the air.
I had a primary drive chain fail on a old Honda 400 Four under full throttle while banked over somewhat in a low-ish speed bend. It didn't break through the case, but the engine sure stopped fast. The 10ms before I pulled in the clutch, and almost getting high-sided afterwards were one of those slow-motion moments I won't forget in a hurry. Fortunately no injuries other than a few pulled muscles from putting my foot down at 40mph.
I'm sure it would have been very interesting at a higher speed.
But some software is developed explicitly for one customer to give them an advantage over their competitors. If you want this software, you're going to have to make it worth the developers while.
Other software just isn't interesting to most developers. Anyone fancy developing a free version of TurboTax and updating it each year as the tax laws change? Didn't think so. If you want to use it you need to pay your fraction of the development costs, plus some.
Free software is great. But free distribution does not by itself result in free software.
Well that would certainly have provided some incentive to develop a workable space-tug technology by now wouldn't it? (assuming there was anyone left alive to do so)
Now, whether it will stay that way with the lack of investment in England after electricity privatization, who can say.
This isn't quite correct. Here's a picture of SpaceShipOne feathered while descending. The fuselage is more or less parallel to the ground, with the wings and tail trailing above/behind to provide stability. I believe the wings are not used as an air brake but rather the fuselage is.
This makes sense because it allows for a wing design that is much lighter than it would otherwise have to be, and hence they can make the ship into a pretty good glider (unlike for example the space shuttle or X15) for the same take-off weight.
It is possible to push the power consumption of the whole device ultimately to below 4 watts while still gaining a travel-TV sized color projection.
Well, a 15-inch LCD panel consumes about 30W, all in. I don't know how big a travel-TV is, but less say it's 7.5inches. Assuming power is proportional to area, then an LCD 7.5-inch travel TV would consume 7.5W. I assume some of that power is absorbed in the colour filters, and some more is lost in the polarizer, and some is used by the TFT itself. So it doesn't seem impossible to me to have a 7.5inch display that consumes 4W.
Of course this could still be vaporware, but I don't think the 4W number is a dead giveaway.
In stating that the GPL is invalid, they are refusing to accept it, and therefore do not have the right to distribute GPL'ed software.
Ideally later on someone would write some useful documentation based on the most helpful feedback.
To some extent, I think the open-source model could be made to work in our favour, if only the right tools were commonly available.
This is not necessarily a contradiction. The CSS algorithm (or business model!) could be patented and published, and the player keys could still be a trade secret.
US
- MIT
- Berkeley
- Stanford
- University of Washington
- UCSD
To a slightly lesser extent:Europe
Asia
Feel free to flame me for who I've missed off :-)
It took me about three hours using the hints. But there's no typo in the hint text - you must have made an error in deciphering.
Allowing encrpyted communication with untrusted hosts is rather like meeting a stranger in a dark alley; whatever happens there won't be any witnesses.
Presumably that indicates 8% packet loss...
H.323 was really a mapping of H.320 ISDN videophones onto IP-based networks. The protocols are all binary.
SIP was designed from scratch for IP networks, and is a test-based protocol with HTTP-like syntax. SIP was also designed from the outset to perform user-location via a search. This makes it appropriate for scenarios where users move around between devices, and hence is good for A/V calls.
Microsoft and Intel opposed SIP from the start. But the telcos waded in, and it turns out they have more say than Microsoft for telephony-style stuff, and in the end Microsoft came to believe in SIP too.
Now whether you'd want to do this, and how you'd index the data in a useful manner are more difficult questions. As are backing the data up. But you could do this now if you wanted to. Food for thought.
VeriSign can't arbitrarily raise their resgistry prices. See Verisign's contract with ICANN, section 22, and also Appendix G.
I guess that's a form of success. But there's probably a reason why everyone else is still doing ground tests.
I control three domains that are currently registered with Versign/Network Solutions. Does anyone have good recommendations for alternative registrars that I can transfer these domains to?
The IAB statement in response to Versign has a lot of technical background on DNS wildcards, what they are, and what the problems with their use are.
Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records.
For zones which do delegations, we do not recommend even wildcard MX records. If they are used, the owners of zones delegated from that zone must be made aware of that policy and must be given assistance to ensure appropriate behavior for MX names within the delegated zone. In other words, the parent zone operator must not reroute mail destined for the child zone without the child zone's permission.
We hesitate to recommend a flat prohibition against wildcards in "registry"-class zones, but strongly suggest that the burden of proof in such cases should be on the registry to demonstrate that their intended use of wildcards will not pose a threat to stable operation of the DNS or predictable behavior for applications and users.
We recommend that any and all TLDs which use wildcards in a manner inconsistent with this guideline remove such wildcards at the earliest opportunity.
I can tell you that the IAB is not perfectly fine with this.
Fzz
In case you were wondering what Brois.
But as for the reasons for not doing earth-orbit rendezvous - I don't think they hold anymore. Back when the plans for Apollo were drawn up, no-one had ever done orbital rendezvous. They were forced to do lunar-orbit rendezvous to make it work at all, but that was with manned spacecraft, so the computers didn't need to be so good. Earth orbit rendezvous missions required automatic docking, which hadn't been done at the time.
These days the Russion Progress supply craft do automatic docking with ISS (and with Mir before) on a regular basis, so that is all known technology. So long as you send the crew up in the re-entry vehicle last, then the risks going out are minimal. If you leave the re-entry vehicle in earth orbit, and you have a spare re-entry vehicle ready to launch just in case, then the risks coming back are relatively low too.
In general, with modern computers to do the docking, I think it's much easier to design the software for orbital rendezvous and to use well-tested smaller rockets than it is to build and test the really big rockets you need to skip the earth-orbit rendezvous stage.
You could also launch the lunar lander, orbital transfer vehicle, and earth lander separately, and rendezvous in earth orbit. I think this would require something larger than a Soyuz launcher, but you could probably do it on something of the size of Ariane 5. Computers are a whole lot better than they were in the 60's, so orbital rendezvous is a lot less risky now than it was back then.
And if you're going to set up a lunar base, taking the Apollo approach makes no sense whatsoever - you want to reuse the orbital transfer vehicle, and as far as possible reuse the lunar lander. The only way to make all this work is to do earth orbit rendezvous.
If the US wanted to do it this way, the ISS would be a big help, but it isn't a requirement.