Actually the moon is the only significant celestial body you really can, in real life, bounce a signal off of and hope to recieve it.
It's just that a roundtrip to the moon is, IIRC, 3 seconds. (I may be off by a factor of two if that's a one-way trip, don't care to look it up.) A simple "dramatic pause" in the announcement will delay the announcement longer then that.;-)
Re:Kicking it off course by a few mm takes 1000 ye
on
Tilting at Asteroids
·
· Score: 2
Orbital mechanics are funny. In an ideal system (no light effects, just straight Newtonian gravity and no external effects), if you go up to a satellite in some orbit and give it some sort of instaneous whack with a stick, the effect is to put the satellite into a new orbit. This orbit will intersect with the old orbit in two places, one where you whacked it and one somewhere else.
Point? If you just change the orbit a little, you don't get anything like a multiplication that you do to estimate how different the satellite's location over time will be then it would have been. In fact you get an oscillation, which with a low enough amplitude will still hit the Earth.
You really want to exert some force over time to change the actual course of the asteroid. I think that's how the painting the asteroid idea comes into play; it changes the dynamic of the applied forces on the asteroid and can have a real effect on where it will be in the future.
I don't mean to be cold but... damages? What damages? She's already terminal, for God's sake.
The worst thing about modern lawsuits is that you don't even have to win to ruin someone. That, plus the fact that damages are whatever a lawyer can convince a judge/jury they are, means it just ain't worth the risk anymore.
May I suggest that while Slashdot may enjoy playing "adaptive device technology developer", because it is kind of fun, you should absolutely do what the parent of this post suggested. This situation is too critical to use anything but proven technology. If you try to kludge something together and it fails, you may end up in a situation you will never forgive yourself for, not to mention anyone else who cares about this woman.
I myself kinda think the idea of biofeedback is neat... but this isn't the time to experiment. Go to the experts and do what they say. Neither you nor the rest of Slashdot put together can possibly match the experiences of the entire community built around supporting these people.
On a more prosaic note, I would be very deeply concerned about the potential legal liability of creating your own solution to this problem. You may find that your best friends are ir(?)rational enough to sue for damages if your homegrown device fails. (On reflection, perhaps that would be perfectly rational behavior, for some definitions of rational. Surprisingly deep philosophical question.)
Amplifying the other response, since ethanol is being promoted as a solution to environmental problems, it hardly makes sense environmentally to spend 1.2x non-earth-safe joules to get 1 so-called-"earth-safe" joule. You end up with a net loss to the environment.
However, not to be excessively flamebait-y, this kind of math is rather typical of many (not all) environmentalists, who seem to care about process more then results. This leaves someone like me, who cares about results, somewhat out in the cold, as I can't stomach calling myself an environmentalist, even though I would like to be one.
It's got to end sometime, folks -- otherwise, we're gonna kill the golden goose.
The golden goose is already on its last gasp, and DRM is the cage for the rest of us that will make sure that not only does it stay dead, but that nobody finds an alternative source of gold, 'cause we'll all be locked in the RIAA cage.
DRM is not about protecting artists, it's about protecting music companies. At least that's the way it's working now. Rest assured were it just about the artists that the RIAA would not bother buying laws that makes DRM impossible to crack.
Frankly - and with due respect to engineers - it *just this attitude* that results in the impossible UI problems that consumers have been facing forever.
I think you mistake the attitude. UI disasters come from anyone who has no training in UI issues, and that's true of many software engineers, and basically all customers.
Keep the context in mind. Customers really can't sit down and tell you what they want. You have to help them work it out, explore alternatives, show them what's possible and what's not, and basically "elicit" the requirements. If the customers could do that stuff, they'd be the engineers.
Customers are not to blame. Engineers listening too literally to the customers without applying expertise and training quite frequently are, however.
Taking it back into context, just because you watch lots of television does not qualify you to create a good television show, or know even how to describe one. Indeed, such a person is likely to fall directly into one of the most popular customer/engineer traps, which is to simply regurgitate designs/programming they've seen in the past and liked, even if it was decidedly sub-optimal. (How many people demand GUIs when they need command line interfaces, and how many people demand(ed) command line interfaces when they needed GUIs? If we let the mass-market customers decide what to program, how many more poor-quality copies of Friends would we end up with? Innovation is challenging!)
First, I'd like to agree and amplify Piquan's sibling comment. Customers don't know what they want. Remember the Simpsons Poochie episode? Check this episode (search the text for "Speedo men", it's the couple of sections below that.).
"Customers don't really know what they want" is virtually the first axiom of software engineering, and it holds for other disciplines as well. (Ask an architect about their customers... not quite as extreme as software, but they still get asked for the moon.)
Second, attempts to bypass Sturgeon's Law generally fail worse then if you just roll with it. Seeing what sticks is a necessary part of the process and can't be removed. It's the way of things.
In fact, you're already in a world where everything is being done to remove risk from the equation, everything is already being done to make sure that the shows stay on the air and aren't mediocre, and it's failing miserably. If the networks had a looser hand, a wider variety of ideas might be tried out, and hey, the next one might be the next Survivor. There's a good reason we recently imported so many show ideas from Britain...
Re:Well, they're not *quite* the same
on
Hacker Survey
·
· Score: 2
Much popular music in the popular genres (note that's two qualifiers!) trades off complexity of composition for a formulaic approach; 4 bars, I-V-IV-I, for instance. A small collection of these exists for most of the popular genres, and you can draw on these a lot without too much complication. That's not because the complication doesn't exist, it's just that it was worked out by someone else.
However, even in the popular genres, you can "compose", and it becomes a challenge again. For instance, the Beatles did a lot of rock that was not simple I-V-IV-I. "Love, Love, Love" (may not be the right title, but you get the idea) is in 5/4, for instance! That's somewhat more challenging to get right, let alone play.
There's a lot of room to play around if one doesn't stick to the narrowest interpretation of the genre. (Not that one has to play good music, of course.)
Yes, the Earth has a zero-G "sweet spot". It's even caused by the same phenomenon as on the Enterprise, cancelling gravitational fields, except this one is real. No, absolutely nothing mentioned in the article will change the zero-G sweet spot Earth has.
Discovery of the location of the "sweet spot" is left as an exercise for the reader, or a student of freshman college physics.
Re:Well, they're not *quite* the same
on
Hacker Survey
·
· Score: 2
Improvisation can be the beginning of a composition, and is a nice quick way to work a theme out, but when actually doing a composition, one must work to flesh it out, explore it, etc., things which vary in proportion by genre but exist in all.
You have to think ahead, look for potential problems, and be much more analytical.
All part of composing, actually. (People sometimes think you can get rid of these but the compositions they create will be the worse for it.) Will this key change write the song into a corner? (Happens quite often, in fact, which surprised me.) I want to get to this new theme, when should it come in and how?
Improvisation can be a fun way to take a break from composing while still staying "in the mood", and perhaps even helping you remember what you're trying to capture in the first place.
This is probably just a normal oscillation the Earth undergoes, driven by the impetus of the various gravitational influences it experiences over time. If we waited around long enough, it would probably start going back.
In fact, just thinking about it, it's virtually inconceivable that it wouldn't oscillate this way. Consider the Earth as a giant drop of water cruising through space. (Note that on a plantary scale, everything is liquid, which is why the surface is smooth. If the Earth were the size of a cue ball, it would be the smoothest cue ball ever made. This is also why blowing up a planet and seeing huge chunks fly away is stupid; it's basically a liquid, it should 'blow up' like one.) Of course it oscillates, what with Saturn and Jupiter and innumerable other influences constantly 'twanging' it.
The only real question is what the period is.
Note that it is utterly inconceivable that humanity has had any significant effect on this process simply by moving mass around. Do a compution on the total mass we've ever moved around, at all. Be generous; go ahead and assume 2002-level industrial output for 10,000 years of human history, which will be an overestimate by about a factor of 5,000. Now divide by the mass of the Earth. Then remember to use your brain when thinking about human effects in the future. (Some things we can and do affect negatively. There are other things we could literally not hope to effect in a million years. Moving a significant fraction of the planet is one of those. Recall the planet is a huge sphere of which "the surface" is itself only a tiny, tiny fraction...)
It might be responsibile for the global warming. I mean since the earth is getting bigger; it means it's getting closer to the sun in a way; so perhaps that's why the Earth is warming up.
MILLIMETERS? I hope you aren't seriously considering that possibility. Our orbit with the sun varies annually by thousands of miles, as it's not a perfect circle. Millimeters won't matter much.
How long before we finally go to far, and the Earth dissolves entirely?
Oh good lord. You can't "dissolve" a planet, no matter how much sci-fi you watch. You must input enough energy into it to overcome gravity, which no amount of drilling will do.
Please get a clue; I mean this not as an insult, but that I really, really wish there were more environmentally concerned people with a clue. If more environmentalists were fighting rationally, maybe they'd make some progress, instead of worrying about stupid things and then making stupid decisions.
Well, they're not *quite* the same
on
Hacker Survey
·
· Score: 3, Interesting
Speaking as someone who has spent significant amounts of time both composing music and writing programs, I can say that they aren't quite the same. Writing music can be much more carthartic (meanings 2) then programming. Composing music, at least the way I did it with a synth so you can hear it right away, can be emotionally freeing in a way that programming can't be.
Flip side, programming can be more exciting, in that it's easier to do something that nobody's done before or better then anybody's done before, with the right tools. Frankly, all the music YOU'LL ever write has basically been written; after hundreds of years of musical development, it's damned hard to find anything new to call your own. (It's not impossible, but very, very, very hard.)
The similarities are otherwise quite significant. With both, you do better and more work when you're "in the zone". There are some days where you just can't get anything done (interestingly, the overlap is not 100%; some days I could write music and not program, and vice versa). There's a lot of freedom, constrained by logic in both. (Whatever you may think, no music anyone will ever want to listen to is completely free of internal logic and consistency, and you violate those rules that we all know, even if we can't articulate them, at your own peril, just as with programming style.)
Run servers, set up home networks, share access with your neighbor. It's all "allowed"...technically, it's all prohibited by their AUP/TOS, but they generally look the other way.
I'm under that arrangement, but that means they have to power to decide on a whim that behavior X, which has been tolerated for 4+ years, is suddenly unacceptable, and if they so desire, they can haul your ass into court for contract violation, or other nasty things.
They may have not used the power, they may not intend to, but reserving the right to haul my ass into court is an intrinsically unfriendly thing they are doing, and I don't like it much. I'd rather see the TOS reflect reality.
I don't see the real question addressed in the article, which is, will this new service have a different TOS agreement (Terms Of Service) then the current service? I'm annoyed enough at being told that I can't run servers, regardless of the bandwidth. I simply will not pay more then I pay now, and still be told that I can run servers, can't VPN, can't this, can't that, can't do anything but consume. (Yes, I tweak the rules with the SSH server that can do anything, but I shouldn't have to.)
On that topic, anybody noticed how almost all of the nasty trends lately that annoy Slashdot denizens boil down to making laws about enforcing the easy things, rather then the illegal things? Instead of enforcing theft laws, make it illegal to change phone ID numbers.... it's easier. Instead of enforcing bandwidth usage (the real money-eater for an ISP), enforce server bans... it's easier. Don't enforce piracy laws, make it illegal to create or use DeCSS and enforce those laws.... it's easier.
I wrote an essay that tangentially touched this issue in the context of automated enforcement a few months ago, but I think the problem is extending out from there. Enforcers of all kind (not just law, AT&T enforces a contract) are getting lazy, and making laws/contracts to help them be lazy.
Yeah, I remember hearing stuff like that, which is why I left the door opened. It's unverified... but of COURSE it's unverified, as to be fair it is exactly the sort of thing the military would justifiably suppress. (That said, I doubt it's useful, but I don't really know.)
Regarding your last paragraph, check my last paragraph. Also, watch your dB, remember, they are exponential. A gun shot tops out at around 140... at 170, they may not have an eardrum left.
(You can get some fun results with that... a nuclear bomb is actually only in the low 200s, as I recall.)
What you describe is not a sound wave, though. Sound is inherently an effect with frequency and amplitude. You describe a pressure wave, which happens to be the way sound waves work, but not all pressure waves are sound waves in the traditional sense of "sound". (Yes, one could craft a definition of sound that works the way you want, but one could do that for anything; it won't match the traditional meaning, nor will most 'rules' regarding sound waves hold up.)
A nuclear bomb produces several huge pressure waves, as do some smaller explosives, but those aren't really sounds... when you get down to small fractions of a Hz, trying to understand them as sound waves will just mislead you. You're better off modeling them as 600Mph limited winds.
Also, remember the context of the conversation... one does not use a "sonic gun" to create these waves, one uses a big-ass explosive. Any sound wave generated by a "sonic gun" as the original poster envisioned is never going to "knock anyone over". See "conservation of momentum".
People's bodies do not have strong resonance frequencies. Without that, nobody's going to be "knocked over" by a sound wave.
"Stun" devices remain science fiction. In fact the idea that a person's nervous system could be somehow incapacitated with sound dates at least back to the late fifties, and you might be able to push it back to the forties or further with some research. (I know I've read fifties-era sci-fi that has sonic stun guns, though, so I'll stick with that.) In fact, it stems from the same misunderstanding promulgated by Star Trek, that everything has a resonance frequency and is just waiting to have havoc done to it by a passing vibrating object. It should not surprise you that the idea has fared about as well as the contemporary rocket jet packs and meals in pill form have fared in real life... what faint vestiges of them exist hardly resemble the '50's conception of them.
This page has a pretty good analysis on the topic, and should probably be considered required reading for all of the budding psuedo-science stun gun designers on Slashdot today.
(By contrast, simply blasting soldiers or rioters with high-energy sounds, distracting sounds, or even (perhaps ideally in the military sense) misleading sound is quite practical, even if less sexy.)
Re:programming zone?
on
Gaming Zone?
·
· Score: 3, Insightful
IMHO, it's nothing mystical, and treating it as such as some people do, while possibly fun, is counterproductive in the end. You can't guarentee entrance, but there are definate concrete steps you can take to get there.
Yeah, reducing entire philosophies to an incorrect one-phrase blurb does tend to produce ridiculousness.
Extropian graphs are like metaphors... they are a way of describing something, but they do not take priority over the real thing. Similarly, those graphs are just a demonstration of the larger point of the difficulty of predicting the near-future in an exponentially-progressing-technology era.
The graphs flow from the arguments, not vice versa.
I wasn't really interested in giving exhaustively correct answers myself, as I've used neither.
He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe
"Marketing" open source is an interesting issue. I think the issues involved in attracting developers and users to your project are not well explored by the community. There should be a 'definitive essay' on the topic, as in 'Homesteading the Noosphere". (I intend to write one in a few years, if my projects are released and do well. Failing that, I'm not qualified, so don't ask me to do it.;-) )
See, the author here has already turned me off and lost. Marketing Open Source should be more honest... 'here's what it's good for, here's what it isn't, here's what needs more work'.
This is what annoys me about this problem. The same 'force' driving the fire (most likely the wind) will drive the smoke in the same direction, so anybody approaching it from the to-be-burned side will die before being able to grab a burning stick.
Too many of these questions disintegrate when considered as a real situation, leaving anybody knowlegable about the subject material out of luck. (Not that I'm a fire expert, but I know something about the topic, which is that Mr. Stuck On The Island better learn to hold his breath. People only rarely burn to death, smoke inhalation is tens or hundreds of times more common.)
To whomever wrote that document: Speaking as a disinterested third party with some experience, the document does not look like a "short comparision", it looks like a Subversion bash fest written by somebody with an axe to grind.
As a simple example, consider
In Subversion, a lot of revision control "smarts" are built into the server. In arch, the smarts reside entirely within the clients. Therefore....
arch is very fast
arch is scalable
arch servers are easy to administer
arch is resiliant when servers fail
arch is better able to recover from server disasters
(numbered for my convenience)
However, this characterization is horribly, obviously lopsided in favor of arch. Putting the smarts on the server is a good thing, because it prevents replication and therefore differences and therefore bugs on the client side, with logic the client should not need to deal with. It makes it harder to write an arch client correctly (witness the profusion of cvs clients).
1 does not follow; a server can often do things faster then a client, because the client may be slow while the server is an 8GHz quad-Sexium with 8 gigs of RAM.
2 does not follow as an advantage; there's nothing that says a server-based solution can't scale, they do all the time.
3 is true, but you're trading off with an entire system (server + clients) that's harder to program correctly because of rampant logic duplications in the clients. It's not an unmitigated advantage in favor of arch, and in fact I read it as an advantage to Subversion.
4 is a nonsequitor; it may be true but it does not follow from being non-centralized. Same for 5. Again, there's no law that servers must be difficult to recover failure from.
This is just one example of an attitude that pervades the linked document. In fact, the article pointed does more to turn me off to arch then anything else. If the author was a developer for arch, I'd be concerned at the lack of experience in design (it is almost never the case that one solution is better then another in every way) and inability to fairly evaluate two products (why not show what both are good for?) being shown here.
Slashdot Mirror
Actually the moon is the only significant celestial body you really can, in real life, bounce a signal off of and hope to recieve it.
;-)
It's just that a roundtrip to the moon is, IIRC, 3 seconds. (I may be off by a factor of two if that's a one-way trip, don't care to look it up.) A simple "dramatic pause" in the announcement will delay the announcement longer then that.
Orbital mechanics are funny. In an ideal system (no light effects, just straight Newtonian gravity and no external effects), if you go up to a satellite in some orbit and give it some sort of instaneous whack with a stick, the effect is to put the satellite into a new orbit. This orbit will intersect with the old orbit in two places, one where you whacked it and one somewhere else.
Point? If you just change the orbit a little, you don't get anything like a multiplication that you do to estimate how different the satellite's location over time will be then it would have been. In fact you get an oscillation, which with a low enough amplitude will still hit the Earth.
You really want to exert some force over time to change the actual course of the asteroid. I think that's how the painting the asteroid idea comes into play; it changes the dynamic of the applied forces on the asteroid and can have a real effect on where it will be in the future.
I don't mean to be cold but... damages? What damages? She's already terminal, for God's sake.
The worst thing about modern lawsuits is that you don't even have to win to ruin someone. That, plus the fact that damages are whatever a lawyer can convince a judge/jury they are, means it just ain't worth the risk anymore.
May I suggest that while Slashdot may enjoy playing "adaptive device technology developer", because it is kind of fun, you should absolutely do what the parent of this post suggested. This situation is too critical to use anything but proven technology. If you try to kludge something together and it fails, you may end up in a situation you will never forgive yourself for, not to mention anyone else who cares about this woman.
I myself kinda think the idea of biofeedback is neat... but this isn't the time to experiment. Go to the experts and do what they say. Neither you nor the rest of Slashdot put together can possibly match the experiences of the entire community built around supporting these people.
On a more prosaic note, I would be very deeply concerned about the potential legal liability of creating your own solution to this problem. You may find that your best friends are ir(?)rational enough to sue for damages if your homegrown device fails. (On reflection, perhaps that would be perfectly rational behavior, for some definitions of rational. Surprisingly deep philosophical question.)
Amplifying the other response, since ethanol is being promoted as a solution to environmental problems, it hardly makes sense environmentally to spend 1.2x non-earth-safe joules to get 1 so-called-"earth-safe" joule. You end up with a net loss to the environment.
However, not to be excessively flamebait-y, this kind of math is rather typical of many (not all) environmentalists, who seem to care about process more then results. This leaves someone like me, who cares about results, somewhat out in the cold, as I can't stomach calling myself an environmentalist, even though I would like to be one.
It's got to end sometime, folks -- otherwise, we're gonna kill the golden goose.
The golden goose is already on its last gasp, and DRM is the cage for the rest of us that will make sure that not only does it stay dead, but that nobody finds an alternative source of gold, 'cause we'll all be locked in the RIAA cage.
DRM is not about protecting artists, it's about protecting music companies. At least that's the way it's working now. Rest assured were it just about the artists that the RIAA would not bother buying laws that makes DRM impossible to crack.
Follow the money.
Frankly - and with due respect to engineers - it *just this attitude* that results in the impossible UI problems that consumers have been facing forever.
I think you mistake the attitude. UI disasters come from anyone who has no training in UI issues, and that's true of many software engineers, and basically all customers.
Keep the context in mind. Customers really can't sit down and tell you what they want. You have to help them work it out, explore alternatives, show them what's possible and what's not, and basically "elicit" the requirements. If the customers could do that stuff, they'd be the engineers.
First Rule of Usability? Don't Listen to Users is a good article.
Customers are not to blame. Engineers listening too literally to the customers without applying expertise and training quite frequently are, however.
Taking it back into context, just because you watch lots of television does not qualify you to create a good television show, or know even how to describe one. Indeed, such a person is likely to fall directly into one of the most popular customer/engineer traps, which is to simply regurgitate designs/programming they've seen in the past and liked, even if it was decidedly sub-optimal. (How many people demand GUIs when they need command line interfaces, and how many people demand(ed) command line interfaces when they needed GUIs? If we let the mass-market customers decide what to program, how many more poor-quality copies of Friends would we end up with? Innovation is challenging!)
First, I'd like to agree and amplify Piquan's sibling comment. Customers don't know what they want. Remember the Simpsons Poochie episode? Check this episode (search the text for "Speedo men", it's the couple of sections below that.).
"Customers don't really know what they want" is virtually the first axiom of software engineering, and it holds for other disciplines as well. (Ask an architect about their customers... not quite as extreme as software, but they still get asked for the moon.)
Second, attempts to bypass Sturgeon's Law generally fail worse then if you just roll with it. Seeing what sticks is a necessary part of the process and can't be removed. It's the way of things.
In fact, you're already in a world where everything is being done to remove risk from the equation, everything is already being done to make sure that the shows stay on the air and aren't mediocre, and it's failing miserably. If the networks had a looser hand, a wider variety of ideas might be tried out, and hey, the next one might be the next Survivor. There's a good reason we recently imported so many show ideas from Britain...
Much popular music in the popular genres (note that's two qualifiers!) trades off complexity of composition for a formulaic approach; 4 bars, I-V-IV-I, for instance. A small collection of these exists for most of the popular genres, and you can draw on these a lot without too much complication. That's not because the complication doesn't exist, it's just that it was worked out by someone else.
However, even in the popular genres, you can "compose", and it becomes a challenge again. For instance, the Beatles did a lot of rock that was not simple I-V-IV-I. "Love, Love, Love" (may not be the right title, but you get the idea) is in 5/4, for instance! That's somewhat more challenging to get right, let alone play.
There's a lot of room to play around if one doesn't stick to the narrowest interpretation of the genre. (Not that one has to play good music, of course.)
Yes, the Earth has a zero-G "sweet spot". It's even caused by the same phenomenon as on the Enterprise, cancelling gravitational fields, except this one is real. No, absolutely nothing mentioned in the article will change the zero-G sweet spot Earth has.
Discovery of the location of the "sweet spot" is left as an exercise for the reader, or a student of freshman college physics.
Improvisation != composing. They're quite different.
Improvisation can be the beginning of a composition, and is a nice quick way to work a theme out, but when actually doing a composition, one must work to flesh it out, explore it, etc., things which vary in proportion by genre but exist in all.
You have to think ahead, look for potential problems, and be much more analytical.
All part of composing, actually. (People sometimes think you can get rid of these but the compositions they create will be the worse for it.) Will this key change write the song into a corner? (Happens quite often, in fact, which surprised me.) I want to get to this new theme, when should it come in and how?
Improvisation can be a fun way to take a break from composing while still staying "in the mood", and perhaps even helping you remember what you're trying to capture in the first place.
This is probably just a normal oscillation the Earth undergoes, driven by the impetus of the various gravitational influences it experiences over time. If we waited around long enough, it would probably start going back.
In fact, just thinking about it, it's virtually inconceivable that it wouldn't oscillate this way. Consider the Earth as a giant drop of water cruising through space. (Note that on a plantary scale, everything is liquid, which is why the surface is smooth. If the Earth were the size of a cue ball, it would be the smoothest cue ball ever made. This is also why blowing up a planet and seeing huge chunks fly away is stupid; it's basically a liquid, it should 'blow up' like one.) Of course it oscillates, what with Saturn and Jupiter and innumerable other influences constantly 'twanging' it.
The only real question is what the period is.
Note that it is utterly inconceivable that humanity has had any significant effect on this process simply by moving mass around. Do a compution on the total mass we've ever moved around, at all. Be generous; go ahead and assume 2002-level industrial output for 10,000 years of human history, which will be an overestimate by about a factor of 5,000. Now divide by the mass of the Earth. Then remember to use your brain when thinking about human effects in the future. (Some things we can and do affect negatively. There are other things we could literally not hope to effect in a million years. Moving a significant fraction of the planet is one of those. Recall the planet is a huge sphere of which "the surface" is itself only a tiny, tiny fraction...)
It might be responsibile for the global warming. I mean since the earth is getting bigger; it means it's getting closer to the sun in a way; so perhaps that's why the Earth is warming up.
MILLIMETERS ? I hope you aren't seriously considering that possibility. Our orbit with the sun varies annually by thousands of miles, as it's not a perfect circle. Millimeters won't matter much.
How long before we finally go to far, and the Earth dissolves entirely?
Oh good lord. You can't "dissolve" a planet, no matter how much sci-fi you watch. You must input enough energy into it to overcome gravity, which no amount of drilling will do.
Please get a clue; I mean this not as an insult, but that I really, really wish there were more environmentally concerned people with a clue. If more environmentalists were fighting rationally, maybe they'd make some progress, instead of worrying about stupid things and then making stupid decisions.
Speaking as someone who has spent significant amounts of time both composing music and writing programs, I can say that they aren't quite the same. Writing music can be much more carthartic (meanings 2) then programming. Composing music, at least the way I did it with a synth so you can hear it right away, can be emotionally freeing in a way that programming can't be.
Flip side, programming can be more exciting, in that it's easier to do something that nobody's done before or better then anybody's done before, with the right tools. Frankly, all the music YOU'LL ever write has basically been written; after hundreds of years of musical development, it's damned hard to find anything new to call your own. (It's not impossible, but very, very, very hard.)
The similarities are otherwise quite significant. With both, you do better and more work when you're "in the zone". There are some days where you just can't get anything done (interestingly, the overlap is not 100%; some days I could write music and not program, and vice versa). There's a lot of freedom, constrained by logic in both. (Whatever you may think, no music anyone will ever want to listen to is completely free of internal logic and consistency, and you violate those rules that we all know, even if we can't articulate them, at your own peril, just as with programming style.)
Run servers, set up home networks, share access with your neighbor. It's all "allowed"...technically, it's all prohibited by their AUP/TOS, but they generally look the other way.
I'm under that arrangement, but that means they have to power to decide on a whim that behavior X, which has been tolerated for 4+ years, is suddenly unacceptable, and if they so desire, they can haul your ass into court for contract violation, or other nasty things.
They may have not used the power, they may not intend to, but reserving the right to haul my ass into court is an intrinsically unfriendly thing they are doing, and I don't like it much. I'd rather see the TOS reflect reality.
I don't see the real question addressed in the article, which is, will this new service have a different TOS agreement (Terms Of Service) then the current service? I'm annoyed enough at being told that I can't run servers, regardless of the bandwidth. I simply will not pay more then I pay now, and still be told that I can run servers, can't VPN, can't this, can't that, can't do anything but consume. (Yes, I tweak the rules with the SSH server that can do anything, but I shouldn't have to.)
On that topic, anybody noticed how almost all of the nasty trends lately that annoy Slashdot denizens boil down to making laws about enforcing the easy things, rather then the illegal things? Instead of enforcing theft laws, make it illegal to change phone ID numbers.... it's easier. Instead of enforcing bandwidth usage (the real money-eater for an ISP), enforce server bans... it's easier. Don't enforce piracy laws, make it illegal to create or use DeCSS and enforce those laws.... it's easier.
I wrote an essay that tangentially touched this issue in the context of automated enforcement a few months ago, but I think the problem is extending out from there. Enforcers of all kind (not just law, AT&T enforces a contract) are getting lazy, and making laws/contracts to help them be lazy.
Yeah, I remember hearing stuff like that, which is why I left the door opened. It's unverified... but of COURSE it's unverified, as to be fair it is exactly the sort of thing the military would justifiably suppress. (That said, I doubt it's useful, but I don't really know.)
Regarding your last paragraph, check my last paragraph. Also, watch your dB, remember, they are exponential. A gun shot tops out at around 140... at 170, they may not have an eardrum left.
(You can get some fun results with that... a nuclear bomb is actually only in the low 200s, as I recall.)
What you describe is not a sound wave, though. Sound is inherently an effect with frequency and amplitude. You describe a pressure wave, which happens to be the way sound waves work, but not all pressure waves are sound waves in the traditional sense of "sound". (Yes, one could craft a definition of sound that works the way you want, but one could do that for anything; it won't match the traditional meaning, nor will most 'rules' regarding sound waves hold up.)
A nuclear bomb produces several huge pressure waves, as do some smaller explosives, but those aren't really sounds... when you get down to small fractions of a Hz, trying to understand them as sound waves will just mislead you. You're better off modeling them as 600Mph limited winds.
Also, remember the context of the conversation... one does not use a "sonic gun" to create these waves, one uses a big-ass explosive. Any sound wave generated by a "sonic gun" as the original poster envisioned is never going to "knock anyone over". See "conservation of momentum".
People's bodies do not have strong resonance frequencies. Without that, nobody's going to be "knocked over" by a sound wave.
"Stun" devices remain science fiction. In fact the idea that a person's nervous system could be somehow incapacitated with sound dates at least back to the late fifties, and you might be able to push it back to the forties or further with some research. (I know I've read fifties-era sci-fi that has sonic stun guns, though, so I'll stick with that.) In fact, it stems from the same misunderstanding promulgated by Star Trek, that everything has a resonance frequency and is just waiting to have havoc done to it by a passing vibrating object. It should not surprise you that the idea has fared about as well as the contemporary rocket jet packs and meals in pill form have fared in real life... what faint vestiges of them exist hardly resemble the '50's conception of them.
This page has a pretty good analysis on the topic, and should probably be considered required reading for all of the budding psuedo-science stun gun designers on Slashdot today.
(By contrast, simply blasting soldiers or rioters with high-energy sounds, distracting sounds, or even (perhaps ideally in the military sense) misleading sound is quite practical, even if less sexy.)
Not only is "the Zone" quite real in programming, one of the most importent aspects of being a great programmer is being able to acheive this state with reasonable reliability. (Nobody can do it all the time.) In fact, smart managers use that to their advantage when figuring out how to organize and manage their programmers.
IMHO, it's nothing mystical, and treating it as such as some people do, while possibly fun, is counterproductive in the end. You can't guarentee entrance, but there are definate concrete steps you can take to get there.
Yeah, reducing entire philosophies to an incorrect one-phrase blurb does tend to produce ridiculousness.
Extropian graphs are like metaphors... they are a way of describing something, but they do not take priority over the real thing. Similarly, those graphs are just a demonstration of the larger point of the difficulty of predicting the near-future in an exponentially-progressing-technology era.
The graphs flow from the arguments, not vice versa.
I wasn't really interested in giving exhaustively correct answers myself, as I've used neither.
;-) )
He may have failed due to his poor writing, but I'm guessing his goal was marketing. You might contact him about it... you know: download arch, get a copy of his tree, write up a patch, and publish the archive. hehehehe
"Marketing" open source is an interesting issue. I think the issues involved in attracting developers and users to your project are not well explored by the community. There should be a 'definitive essay' on the topic, as in 'Homesteading the Noosphere". (I intend to write one in a few years, if my projects are released and do well. Failing that, I'm not qualified, so don't ask me to do it.
See, the author here has already turned me off and lost. Marketing Open Source should be more honest... 'here's what it's good for, here's what it isn't, here's what needs more work'.
This is what annoys me about this problem. The same 'force' driving the fire (most likely the wind) will drive the smoke in the same direction, so anybody approaching it from the to-be-burned side will die before being able to grab a burning stick.
Too many of these questions disintegrate when considered as a real situation, leaving anybody knowlegable about the subject material out of luck. (Not that I'm a fire expert, but I know something about the topic, which is that Mr. Stuck On The Island better learn to hold his breath. People only rarely burn to death, smoke inhalation is tens or hundreds of times more common.)
As a simple example, consider (numbered for my convenience)
However, this characterization is horribly, obviously lopsided in favor of arch. Putting the smarts on the server is a good thing, because it prevents replication and therefore differences and therefore bugs on the client side, with logic the client should not need to deal with. It makes it harder to write an arch client correctly (witness the profusion of cvs clients).
1 does not follow; a server can often do things faster then a client, because the client may be slow while the server is an 8GHz quad-Sexium with 8 gigs of RAM.
2 does not follow as an advantage; there's nothing that says a server-based solution can't scale, they do all the time.
3 is true, but you're trading off with an entire system (server + clients) that's harder to program correctly because of rampant logic duplications in the clients. It's not an unmitigated advantage in favor of arch, and in fact I read it as an advantage to Subversion.
4 is a nonsequitor; it may be true but it does not follow from being non-centralized. Same for 5. Again, there's no law that servers must be difficult to recover failure from.
This is just one example of an attitude that pervades the linked document. In fact, the article pointed does more to turn me off to arch then anything else. If the author was a developer for arch, I'd be concerned at the lack of experience in design (it is almost never the case that one solution is better then another in every way) and inability to fairly evaluate two products (why not show what both are good for?) being shown here.