It's possible that LLVM-based tools may be approaching the point where they could supplant GCC, but this project doesn't seem all that important to that goal. There are definitely niches where a fast debugger matters, but that's exactly what they are--niches. A faster debugger is very, very low on the list of things that would help you compete with the GCC toolchain.
Things like supporting variadic templates, having a wider array of backends, and the like are far more important if you want to displace GCC--the backends, in particular, make clang a total non-starter for many embedded developers.
That's not to say the fast debugger isn't a good development--for things that need it, it's very valuable indeed. But the attempted spin of the blurb seems to miss the point.
I think we are going in circles here. where is the energy input to a closed system?
It's not a closed system. Wind is providing energy.
put this another way, if you are moving with the wind at the windspeed then the propeller blade cannot know which way the wind is blowing. all directions are equal to it, regardless of the pitch of the blade. So this blade pitch argument is a red herring.
But if the propeller is rotating relative to the car, then the velocity of the blades (particularly near the tip) is different from that of the car. If the car's velocity is the same as the wind's, then the propeller tips' velocity is different, which is what allows them to capture wind energy.
The propeller tips are transverse to the wind when the cart is traveling downwind--note the parenthetical "downwind relative to the ground" in the final paragraph, as well as the note that forward thrust provided in that situation can be larger than the wind velocity.
In fact, getting the "sail" equivalents (prop tips) transverse to the wind while the vehicle is traveling downwind is the entire point of the vehicle's setup.
The propeller tips are transverse to the wind when the cart is traveling downwind--note the parenthetical "downwind relative to the ground" in the final paragraph.
In fact, getting the "sail" equivalents (prop tips) transverse to the wind while the vehicle is traveling downwind is the entire point of the vehicle's setup.
The kinetic energy of the net movement of earth and of the atmosphere (in the centre of mass frame) is thermodynamically available and (neglecting friction and relativity) can accerate a sufficiently light mass arbitrarilly fast. Thus, DDWFTTW is obviously not physically impossible (and numerous conceptually-trivial schemes have been suggested).
It is empirically known that yachts or sailing boats can continuously travel diagonally with (as well as against) the wind at speeds (such that even the component of their velocity in the direction of the wind is) significantly faster than the wind.
In the boat's frame of reference (assuming steady nonaccelerating state, inviscid flow, etc) the sail can be oriented such that any (sufficiently) diagonal headwind (or tailwind) is redirected more into the sternward direction (with the same speed, by conservation of energy), such that the reaction force on the boat (while mostly perpendicular to the keel) has a positive component in the direction of the bow; (neglecting friction) a sailboat can accelerate forward as long as the wind relative to the boat is not arriving directly from the front.
In the water's frame of reference (assuming the boat is already moving forward) this redirected breeze is always slower than the incoming wind (draw the trig'), losing energy and momentum to the boat (later frictioned to the water), independent of how fast this lets the boat accelerate compared to the windspeed. (Learn More)
The simple idea behind the fan and wheeled trolly contraption is that the belt (which couples their respective axels) performs exactly the role of the sailboat's keel (imagine sailing on a ringworld). The belt/gear ratio constrains the propellor-tip to move through space on a fixed helical trajectory of constant diagonalness (the ratio of forward to transverse motion, or pitch to circumference), ensuring that (as long as the atmosphere is moving forward relative to the ground) the propellor tips are never moving directly into the wind and thus (identifying the propellor blade with a yacht's sail) a forward thrust component can be obtained regardless of whether the velocity of the cart itself is less, equal or more than the wind velocity.
The limiting factors are the aforementioned ratio, the fixed-angle pitch of the propellor-tip's blade-sail, the windspeed (relative to the ground), drag and friction. For any constant windspeed, the ratio and the propellor sail-pitch together determine a maximum cart velocity (downwind relative to the ground) at which forward thrust can be produced (this can be larger than the wind velocity but not infinite) but it is a tradeoff because the ratio simultaneously increases drag, and (with the ratio also fixed) tuning the propellor sail-pitch for higher cart-velocity decreases its efficiency at lower cart velocities.
You don't need input energy to maintain your momentum--you only need enough input energy to overcome friction/drag, anything beyond that can accelerate you.
Because there is an energy input into the system (wind). The car's momentum will tend to keep it moving at its current speed, so the wind power only has to be enough to overcome friction/drag for the car to accelerate. The wheels and prop are directly linked (they can't rotate independently--if you held the prop still and turned the wheels or vice-versa, you'd break the car).
Basically, the blades of the prop act like tacking sails; once you get your head around that it becomes easy to see that it works.
It should be obvious that the vegetarian argument is based upon a creature's capacity to experience pain and suffering...Our best data suggest that plants cannot experience anything at all (much less pain and suffering), hence there is no moral argument against using them as a food source.
That's fairly simplistic, and I'm not convinced it's true (though I'm not convinced it's false, either).
Plants definitely take action in response to physical attacks.
A few responses to physical harm that have been observed in some plant species: 1: Evasive acts, including closing of flowers, and emitting pheromones that predators dislike 2: Signalling other nearby plants to take similar actions 3: Emitting pheromones that attract insectivores as an interspecies defense mechanism
It's certainly possible that they're not experiencing pain and suffering, and merely engaging in stimulus/response behavior. OTOH, when a living creature actually takes action to defend itself and to alert those nearby to harm, it's tough for me to be 100% convinced that it's not feeling pain and suffering at least on some level (though possibly in a way that's very different from our own).
Rich Young once summarized it in what strikes me as a fairly balanced manner:
At its base, pain can be viewed as a warning to the organism that experiences it, that it's life and/or ability to propagate its genetic heritage is under threat. It can be argued that organisms are essentially [as some wag once said] "DNA's way of making more DNA." Virtually ALL organisms have sensory mechanisms that are aimed at warning the individual of threats to life and/or reproduction, thus, while plants probably can't "feel pain" (as defined in human dictionaries), plants can certainly sense their environment and react in ways that are clearly intended to minimize threats to life and/or reproduction: threats that humans would interpret as painful. In other words, whatever one chooses to call it, plants certainly experience the *functional equivalent* of that which we humans call "pain"
That said, it's entirely consistent to me even if you admit that plants do have some capacity for feeling to believe it's so alien, primitive, or instinctual compared to our own as to be on a different moral level.
It strikes me that a better use of a fourth colour pixel would be to represent all those greens the RGB colour space doesn't actually represent.
Nit: sRGB isn't synonymous RGB, nor even with RGB as used in displays.
Plenty of RGB colorspaces don't have the green-deficiency problem, and it's nothing innately required by an RGB LED system if it's willing to do a non-sRGB display.
Once you put a fan in it, it's not silent. Even underclocked 120 mm fans with good bearings make some noise.
When I built my htpc 9 years ago, finding a suitable fanless power supply and silent drives were the major hurdles. The second is easily solved without searching nowadays; the first still requires a bit of digging.
It may be obvious, but there isn't really a technical barrier here on the navigation capability (as opposed to the UI and possibly implementation in some programs). In most decent document reading programs, it's trivial to set lots bookmarks and flip back and forth between pages much more easily than you can with paper.
On top of that, there's often fast domain-specific navigation (e.g. jumping from chapter to chapter, drilling through function calls in code, grabbing references, skipping to and from the index), searching, and all kinds of other great reading aids.
And yet I still find people printing out documents that we're reviewing coming by and saying "here, I printed out a copy for everyone" and dropping a copy "helpfully" on my desk--which I hate, because I'm never going to look at it and that paper is wasted (sure, it's still got the back for scratch paper, but it's still somewhat wasted).
This leads me to think there are a few major problems: 1. Program user interfaces aren't exposing bookmark functionality enough--this is a major time saver, and one of the prime reasons I hear people saying they print stuff out is so they can flip between 2 or 3 things quickly when that should absolutely be a reason to prefer reading online. 2. People aren't learning their tools effectively; for those who are often using a particular document reader as part of the job, it's worth putting a little effort into learning how it can help you. 3. As the OP notes, markup can be restrictive--this is especially true for domain-specific markup (e.g. the common editor's symbols like squiggly underlines, paragraph begin/move, arrows running from here to there, etc). This is partially because those markups were designed for a different medium, and partially because many apps don't make a strong effort to support flexible markup 4. People don't like computer monitors for some reason. I think this is sometimes true, but often overstated--a lot of people make this claim when the real problem lies elsewhere. For those who really have trouble with modern screens, it's a tough problem though perhaps OLEDs, e-ink style displays, or some other advance will eventually offer a solution
But I think an equally large problem is simple habit. People are used to flipping through paper, to the point that they even assume other people feel the same way and "helpfully" print everything out even for those who would much rather have it online. And it happens in all kinds of domains: Post-it notes get stuck to my monitor when an email would've been easier for both of us, faxes of photos get sent instead of just attaching the image or sending a link to it, etc.
The best available evidence on how salt consumption affects our health comes from observational studies, in which groups of subjects are investigated to identify any correlations between usual sodium intake and subsequent heart attacks and strokes. Nine such studies, looking at a total of more than 100,000 participants who consume as much sodium as New Yorkers do, have had mixed results. In four of them, reduced dietary salt was associated with an increased incidence of death and disability from heart attacks and strokes. In one that focused on obese people, more salt was associated with increased cardiovascular mortality. And in the remaining four, no association between salt and health was seen.
The article also references other studies showing the opposite, but its basic point is pretty clear: we really don't know enough about the generalized effects of altering sodium intake to make any broad sweeping health recommendations yet.
The evidence isn't irrefutable yet -- nobody has taken a large population and randomly divided them into a high-salt and low-salt group for 15 years, and they probably never will. Excess salt is probably safe for young, healthy people. But nobody stays young and healthy forever.
The major problem is that not only isn't the evidence irrefutable, it's also conflicting; a lot of studies show that decreasing salt intake increases mortality rates.
But what really matters is whether reducing salt will ultimately prevent heart attacks and strokes and thus improve or extend life...Nine such studies, looking at a total of more than 100,000 participants who consume as much sodium as New Yorkers do, have had mixed results. In four of them, reduced dietary salt was associated with an increased incidence of death and disability from heart attacks and strokes. In one that focused on obese people, more salt was associated with increased cardiovascular mortality. And in the remaining four, no association between salt and health was seen.
There's more in the article, including some study results that tend to indicate the opposite, but the overall takeaway is that there's a lot more we need to learn before we rush to change things.
EDIT: the more I read the article, the angrier I get.
It's really pretty close to claiming that one limited test shows that Python or Tcl or Ruby or C# or Perl or Java or ColdFusion or whatever (call it language X) is only 20% slower than C, therefore people who claim language X is slower than C are idiots.
The purported "evidence" against it is actually supporting the Mythical Man Months' theory.
Even there, they didn't come anywhere close to disproving Brooks' theory.
If you throw 20 programmers at a task, the square root of 20 is 4.472+. They got a factor of 4 (at best) improvement. To even begin to claim that productivity improves with the number of programmers (modulo a constant), they'd need to beat that square root.
They failed. The numbers they're quoting are certainly inconclusive, but in a vacuum they support a sub-linear improvement (the Brooks hypothesis), they don't refute it.
Certainly there could be a very small constant where these results are inline with a non-Brooksian conclusion, but in a vacuum they're more likely in line with a Brooksian hypothesis than any theory of linear scaling.
A better example might be people seeing the French Connection and complaining that the car chase is too much of a cliche in a cop movie. (When they aren't aware that the French Connection is the *reason* every cop movie made since has a car chase.)
I think Bullitt has more of a claim to fame as the *reason* every cop movie made has a car chase. Friedkin himself says that it was the Bullitt car chase that inspired him to try to outdo it in the French Connection.
Whether he succeeded in doing so is a matter approximately as well-settled as the question of emacs vs. vi.
Why is it your neighbor's responsibility to use their property in a way they dislike in order to bolster your property values?
I live in Virginia now, and this nonsense goes on not only in HOAs but even with city ordinances--mandating grass cutting, forbidding painting your house certain colors, etc. I just don't get it--in Maine, if you wanted a hot pink house with lines of toy soldiers and an above ground pool on your front lawn, that was your own business. It's your own property, and you have a right to use it how you want within the bounds of safety and environmental concerns.
Now, if it's a safety issue that's another thing. But the state's interest in defending property should be first and foremost to defend the right of a property's owner to use it as they see fit; if you want to have crazy aesthetic restrictions then you can move into an area with a draconian HOA.
Your water pipe issue is completely different, and I sympathize greatly.
Why do you think it's necessary to attend the game? I can just as easily learn those facts by watching the game on tv
Then you would not be subject to any terms printed on a ticket, since you didn't use a ticket, assuming you didn't otherwise enter a contractual relationship with NFL that had some strange requirements.
Right--that's the point of the question. Why do you think the discussion is at all about tickets, or attending the game? You're the one who brought those things up and you keep harping on them, but they're not what anyone else was talking about beforehand.
Notice how the post you originally responded to is talking about the right to prohibit descriptions or accounts *of the copyrighted broadcast* and you jump in with the ticket tangent:
Like the NFL example given above - "pictures, descriptions or accounts of the game without the permission of the NFL are prohibited." Copyright does not give them the right to prohibit descriptions or accounts of the copyrighted broadcast, so that copyright notice should be illegal and they should be substantially fined for it.
Copyright does give them the right to prohibit descriptions or accounts of the game. It's part of the contract terms to buy a ticket, that NFL gets assigned those copyrights.
I would ask, why would you even allow password-based logins to your server?
Because requiring key files presents a barrier to the ability to do work, and that penalty is far greater than the small risk of being hacked in a manner that's caused by allowing password-based logins.
It's not unheard of for things to go wonky when a key employee's on vacation or over at a friend's house or wherever, and the benefit we get from having them be able to download putty, log in, and fix things is a lot higher than the tradeoff.
In a security-focused sysadmin's world it'd be nice to tell them they should carry a keyfile with them everywhere, but in the real world that doesn't really work out all the time.
This is the wrong place to ask. I doubt we'll get a single response from a person on the cutting edge of cryptanalysis who can give you a meaningful answer on the relative strength of Diffe-Hellman vs AES, which is what your question comes down to.
No, it doesn't.
Currently, the relative strength of both of those is "much stronger than the chance of some kind of user screwup". Something like typing a password and "enter" into the wrong window, connecting to the wrong server, being tired and cranky about having to get work done and so ignoring a KEY CHANGE warning, etc is far more likely than an attacker breaking AES or Diffie-Hellman to get to your data.
So, do what you can to minimize the chance of user error. To me, that probably means stay connected (I'm willing to be persuaded otherwise, though, whether in general or for particular work patterns).
Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?
Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected, since by far the biggest danger is user errors: you accidentally connecting to the wrong serves, ignoring a cert change alert or something else boneheaded.
Assuming you're not using SSH1, the client and server should periodically regenerate session keys, so it's not like you'll be encrypting vast sessions with just one key (not that this is likely to be the biggest point of failure in your system even without re-keying).
Which was also predated by a few thousand years by Go, the one true game which all games derive.
Go dates to c 500 BC, possibly somewhat earlier; that makes it a relative newcomer, only about as old as things like Parcheesi, Nine Men's Morris, and Liubo.
Backgammon, Sennet, and the Royal Ur Game go back two or three thousand years earlier than Go.
uhhh...i hate to rain on your parade...but isnt "3 or 4" dropped calls pretty much around your own quoted number of 30%?
If the 3-4 out of a couple of dozen is to be believed, it's about half that. 3/24 = 12.5%, 4/24 = 16.7%.
That's still disgustingly high, though. I've had 1 dropped phone in the 6 months that I've had my iPhone, but I don't live in NYC; if I were getting even 1% dropped calls, I'd switch phones in a heartbeat.
Slashdot Mirror
It's possible that LLVM-based tools may be approaching the point where they could supplant GCC, but this project doesn't seem all that important to that goal. There are definitely niches where a fast debugger matters, but that's exactly what they are--niches. A faster debugger is very, very low on the list of things that would help you compete with the GCC toolchain.
Things like supporting variadic templates, having a wider array of backends, and the like are far more important if you want to displace GCC--the backends, in particular, make clang a total non-starter for many embedded developers.
That's not to say the fast debugger isn't a good development--for things that need it, it's very valuable indeed. But the attempted spin of the blurb seems to miss the point.
It's not a closed system. Wind is providing energy.
But if the propeller is rotating relative to the car, then the velocity of the blades (particularly near the tip) is different from that of the car. If the car's velocity is the same as the wind's, then the propeller tips' velocity is different, which is what allows them to capture wind energy.
Whoops, replied to myself instead of you.
The propeller tips are transverse to the wind when the cart is traveling downwind--note the parenthetical "downwind relative to the ground" in the final paragraph, as well as the note that forward thrust provided in that situation can be larger than the wind velocity.
In fact, getting the "sail" equivalents (prop tips) transverse to the wind while the vehicle is traveling downwind is the entire point of the vehicle's setup.
The propeller tips are transverse to the wind when the cart is traveling downwind--note the parenthetical "downwind relative to the ground" in the final paragraph.
In fact, getting the "sail" equivalents (prop tips) transverse to the wind while the vehicle is traveling downwind is the entire point of the vehicle's setup.
Physicsforum explained it well at http://www.physicsforums.com/showthread.php?t=274996
A more thorough look from the Straight Dope, which also notes that America's Cup yachts travel at 2 to 3 times the speed of the winds propelling them:
http://www.straightdope.com/columns/read/2908/how-can-racing-yachts-sail-faster-than-the-wind
Huh? That's news to all the sailors out there who do routinely sail faster than the wind.
Physics explained here in the "How can boats sail faster than the wind?" section:
http://www.animations.physics.unsw.edu.au/jw/sailing.html
You don't need input energy to maintain your momentum--you only need enough input energy to overcome friction/drag, anything beyond that can accelerate you.
Because there is an energy input into the system (wind). The car's momentum will tend to keep it moving at its current speed, so the wind power only has to be enough to overcome friction/drag for the car to accelerate. The wheels and prop are directly linked (they can't rotate independently--if you held the prop still and turned the wheels or vice-versa, you'd break the car).
Basically, the blades of the prop act like tacking sails; once you get your head around that it becomes easy to see that it works.
That's fairly simplistic, and I'm not convinced it's true (though I'm not convinced it's false, either).
Plants definitely take action in response to physical attacks.
A few responses to physical harm that have been observed in some plant species:
1: Evasive acts, including closing of flowers, and emitting pheromones that predators dislike
2: Signalling other nearby plants to take similar actions
3: Emitting pheromones that attract insectivores as an interspecies defense mechanism
It's certainly possible that they're not experiencing pain and suffering, and merely engaging in stimulus/response behavior. OTOH, when a living creature actually takes action to defend itself and to alert those nearby to harm, it's tough for me to be 100% convinced that it's not feeling pain and suffering at least on some level (though possibly in a way that's very different from our own).
Rich Young once summarized it in what strikes me as a fairly balanced manner:
That said, it's entirely consistent to me even if you admit that plants do have some capacity for feeling to believe it's so alien, primitive, or instinctual compared to our own as to be on a different moral level.
http://www.wired.com/wiredscience/2009/11/plant-family-values is also sort of interesting; it shows some sort of community behavior, though titling it "family values" is obviously polemical.
Nit: sRGB isn't synonymous RGB, nor even with RGB as used in displays.
Plenty of RGB colorspaces don't have the green-deficiency problem, and it's nothing innately required by an RGB LED system if it's willing to do a non-sRGB display.
Once you put a fan in it, it's not silent. Even underclocked 120 mm fans with good bearings make some noise.
When I built my htpc 9 years ago, finding a suitable fanless power supply and silent drives were the major hurdles. The second is easily solved without searching nowadays; the first still requires a bit of digging.
It may be obvious, but there isn't really a technical barrier here on the navigation capability (as opposed to the UI and possibly implementation in some programs). In most decent document reading programs, it's trivial to set lots bookmarks and flip back and forth between pages much more easily than you can with paper.
On top of that, there's often fast domain-specific navigation (e.g. jumping from chapter to chapter, drilling through function calls in code, grabbing references, skipping to and from the index), searching, and all kinds of other great reading aids.
And yet I still find people printing out documents that we're reviewing coming by and saying "here, I printed out a copy for everyone" and dropping a copy "helpfully" on my desk--which I hate, because I'm never going to look at it and that paper is wasted (sure, it's still got the back for scratch paper, but it's still somewhat wasted).
This leads me to think there are a few major problems:
1. Program user interfaces aren't exposing bookmark functionality enough--this is a major time saver, and one of the prime reasons I hear people saying they print stuff out is so they can flip between 2 or 3 things quickly when that should absolutely be a reason to prefer reading online.
2. People aren't learning their tools effectively; for those who are often using a particular document reader as part of the job, it's worth putting a little effort into learning how it can help you.
3. As the OP notes, markup can be restrictive--this is especially true for domain-specific markup (e.g. the common editor's symbols like squiggly underlines, paragraph begin/move, arrows running from here to there, etc). This is partially because those markups were designed for a different medium, and partially because many apps don't make a strong effort to support flexible markup
4. People don't like computer monitors for some reason. I think this is sometimes true, but often overstated--a lot of people make this claim when the real problem lies elsewhere. For those who really have trouble with modern screens, it's a tough problem though perhaps OLEDs, e-ink style displays, or some other advance will eventually offer a solution
But I think an equally large problem is simple habit. People are used to flipping through paper, to the point that they even assume other people feel the same way and "helpfully" print everything out even for those who would much rather have it online. And it happens in all kinds of domains: Post-it notes get stuck to my monitor when an email would've been easier for both of us, faxes of photos get sent instead of just attaching the image or sending a link to it, etc.
Not only that, but the effect is somewhat variable--in some people, reducing sodium intake increases blood pressure. And the overall health benefits are still a matter of debate. See, for instance:
http://www.nytimes.com/2009/02/06/opinion/06alderman.html?_r=3&emc=eta1
The best available evidence on how salt consumption affects our health comes from observational studies, in which groups of subjects are investigated to identify any correlations between usual sodium intake and subsequent heart attacks and strokes. Nine such studies, looking at a total of more than 100,000 participants who consume as much sodium as New Yorkers do, have had mixed results. In four of them, reduced dietary salt was associated with an increased incidence of death and disability from heart attacks and strokes. In one that focused on obese people, more salt was associated with increased cardiovascular mortality. And in the remaining four, no association between salt and health was seen.
The article also references other studies showing the opposite, but its basic point is pretty clear: we really don't know enough about the generalized effects of altering sodium intake to make any broad sweeping health recommendations yet.
The major problem is that not only isn't the evidence irrefutable, it's also conflicting; a lot of studies show that decreasing salt intake increases mortality rates.
See, e.g., http://www.nytimes.com/2009/02/06/opinion/06alderman.html?_r=3&emc=eta1
For most people, wide swings in dietary sodium consumption don’t affect blood pressure, and for some, blood pressure actually rises when they lower their salt intake.
But what really matters is whether reducing salt will ultimately prevent heart attacks and strokes and thus improve or extend life...Nine such studies, looking at a total of more than 100,000 participants who consume as much sodium as New Yorkers do, have had mixed results. In four of them, reduced dietary salt was associated with an increased incidence of death and disability from heart attacks and strokes. In one that focused on obese people, more salt was associated with increased cardiovascular mortality. And in the remaining four, no association between salt and health was seen.
There's more in the article, including some study results that tend to indicate the opposite, but the overall takeaway is that there's a lot more we need to learn before we rush to change things.
EDIT: the more I read the article, the angrier I get.
It's really pretty close to claiming that one limited test shows that Python or Tcl or Ruby or C# or Perl or Java or ColdFusion or whatever (call it language X) is only 20% slower than C, therefore people who claim language X is slower than C are idiots.
The purported "evidence" against it is actually supporting the Mythical Man Months' theory.
Even there, they didn't come anywhere close to disproving Brooks' theory.
If you throw 20 programmers at a task, the square root of 20 is 4.472+. They got a factor of 4 (at best) improvement. To even begin to claim that productivity improves with the number of programmers (modulo a constant), they'd need to beat that square root.
They failed. The numbers they're quoting are certainly inconclusive, but in a vacuum they support a sub-linear improvement (the Brooks hypothesis), they don't refute it.
Certainly there could be a very small constant where these results are inline with a non-Brooksian conclusion, but in a vacuum they're more likely in line with a Brooksian hypothesis than any theory of linear scaling.
A better example might be people seeing the French Connection and complaining that the car chase is too much of a cliche in a cop movie. (When they aren't aware that the French Connection is the *reason* every cop movie made since has a car chase.)
I think Bullitt has more of a claim to fame as the *reason* every cop movie made has a car chase. Friedkin himself says that it was the Bullitt car chase that inspired him to try to outdo it in the French Connection.
Whether he succeeded in doing so is a matter approximately as well-settled as the question of emacs vs. vi.
Why is it your neighbor's responsibility to use their property in a way they dislike in order to bolster your property values?
I live in Virginia now, and this nonsense goes on not only in HOAs but even with city ordinances--mandating grass cutting, forbidding painting your house certain colors, etc. I just don't get it--in Maine, if you wanted a hot pink house with lines of toy soldiers and an above ground pool on your front lawn, that was your own business. It's your own property, and you have a right to use it how you want within the bounds of safety and environmental concerns.
Now, if it's a safety issue that's another thing. But the state's interest in defending property should be first and foremost to defend the right of a property's owner to use it as they see fit; if you want to have crazy aesthetic restrictions then you can move into an area with a draconian HOA.
Your water pipe issue is completely different, and I sympathize greatly.
Right--that's the point of the question. Why do you think the discussion is at all about tickets, or attending the game? You're the one who brought those things up and you keep harping on them, but they're not what anyone else was talking about beforehand.
Notice how the post you originally responded to is talking about the right to prohibit descriptions or accounts *of the copyrighted broadcast* and you jump in with the ticket tangent:
I would ask, why would you even allow password-based logins to your server?
Because requiring key files presents a barrier to the ability to do work, and that penalty is far greater than the small risk of being hacked in a manner that's caused by allowing password-based logins.
It's not unheard of for things to go wonky when a key employee's on vacation or over at a friend's house or wherever, and the benefit we get from having them be able to download putty, log in, and fix things is a lot higher than the tradeoff.
In a security-focused sysadmin's world it'd be nice to tell them they should carry a keyfile with them everywhere, but in the real world that doesn't really work out all the time.
This is the wrong place to ask. I doubt we'll get a single response from a person on the cutting edge of cryptanalysis who can give you a meaningful answer on the relative strength of Diffe-Hellman vs AES, which is what your question comes down to.
No, it doesn't.
Currently, the relative strength of both of those is "much stronger than the chance of some kind of user screwup". Something like typing a password and "enter" into the wrong window, connecting to the wrong server, being tired and cranky about having to get work done and so ignoring a KEY CHANGE warning, etc is far more likely than an attacker breaking AES or Diffie-Hellman to get to your data.
So, do what you can to minimize the chance of user error. To me, that probably means stay connected (I'm willing to be persuaded otherwise, though, whether in general or for particular work patterns).
SSH doesn't use SSL, and SSHv2 has provisions for rekeying even during a single connection.
Is it safer to log out of an SSH session, and re-establish it later, or just keep the connection open?
Breaking the crypto is almost assuredly not the weakest point in your connection. I'd stay connected, since by far the biggest danger is user errors: you accidentally connecting to the wrong serves, ignoring a cert change alert or something else boneheaded.
Assuming you're not using SSH1, the client and server should periodically regenerate session keys, so it's not like you'll be encrypting vast sessions with just one key (not that this is likely to be the biggest point of failure in your system even without re-keying).
Which was also predated by a few thousand years by Go, the one true game which all games derive.
Go dates to c 500 BC, possibly somewhat earlier; that makes it a relative newcomer, only about as old as things like Parcheesi, Nine Men's Morris, and Liubo.
Backgammon, Sennet, and the Royal Ur Game go back two or three thousand years earlier than Go.
If the 3-4 out of a couple of dozen is to be believed, it's about half that. 3/24 = 12.5%, 4/24 = 16.7%.
That's still disgustingly high, though. I've had 1 dropped phone in the 6 months that I've had my iPhone, but I don't live in NYC; if I were getting even 1% dropped calls, I'd switch phones in a heartbeat.