That piece is kind of crap. The main reason is that the summer holidays are over. The kids are in school (and busy with clubs, homework and so on on the weekends) and the parents are working. And as most bathers are gone, so are the drink vendors, the equipment renters and so on.You'll still find people on beaches, just not many.
Maybe you're just from somewhere other than Europe, where a rabbit in the moon is the more common image: http://en.wikipedia.org/wiki/M...
Does TFA mean a big volcano or a million volcanos?
>Every protocol that runs over RS232
Protocols that run over RS232 are not RS232. RS232 is the interface spec.
Is a quasi-moon like a quasi -planet (i.e., Pluto)?
Nope. Pluto's designation is based on it's size, mostly. The category "planet", like all categories, is made by humans to conveniently describe the universe to ourselves, and the precise boundaries are constrained (but not determined) by how the universe actually is and how we actually are. Within those constraints we can put the boundary where we like, and in the case of planets, smaller bodies that don't dominate their gravitational neighbourhood have been deemed to fall outside the human-created category we use the word "planet" to label.
Quasi-moons are bodies in solar orbits that have interacted with their quasi-primary such that they are "station keeping" with it. A body like this one will wander around in the general vicinity of Earth as both Earth and quasi-moon travel around the sun together. So from the perspective of an observer on Earth, the quasi-moon executes periodic but non-orbital motion: it wanders in a closed configuration that does not describe a path that goes around the Earth.
This is, like many such distinctions, fairly arbitrary: the sun's gravity at the orbit of the Moon is a good deal stronger than the Earth's gravity at the orbit of the Moon, so one could describe the Moon as being in orbit about the sun, with it's orbit perturbed into a wobble by the nearby Earth. That is, from an outside observer's perspective, the Moon's motion is never retrograde with respect to it's mutual orbit with Earth around the sun.
Consider the view:
O o .
where the O is the sun, the o is the Earth and the . is the Moon. In the configuration shown (with the Moon on the outer wobble of its orbit about the Sun) it is moving faster than average (imagine the Earth and Moon both rotation clockwise around the Sun, and the Moon moving clock-wise around the Earth, so when in the image above it is moving "down" on the page).
But in the situation that obtains two weeks later:
O . o
where the Moon on the inner wobble of its orbit about the Sun, it is still moving "down" on the page relative to the Sun even though it is moving "up" on the page from the perspective of an observer on Earth.
Another way to see this is to consider that the Moon executes a wobble like this once a month, traveling 2*pi*0.25 million miles (lunar orbit is about 250 thousand miles), but at the same time moves 2*pi*96/12 million miles in its orbit around the Sun (which is 96 million miles from Earth), and since 96/12 > 0.25 it should be clear that the Moon's orbital velocity around the Sun is higher than it's orbital velocity around the Earth. Ergo: no retrograde motion for the Moon!
All of this is a very long-winded way of saying: how we classify Moons vs quasi-moons is useful, but--as with all the ways we as knowing subjects classify the objectively real universe we live in--somewhat arbitrary. We could--but don't, so far as I know--have a name for the class of moon-like objects that have orbital velocities around their primary that are greater than their orbital velocity around their primary's primary (most Earth-orbiting satellites fall into this category.) Instead, we have a name for objects that don't execute motions relative to their (quasi-)primary that look like a loop around it from the perspective of an observer on the primary's surface.
I've worked on-and-off in healthcare and the standards for transmitting *anything* are ancient and bad. Formats like HL7 and ASTM are ancient delimited-text formats with no UTF-8 support, no encryption, and even have RS232 ACK/NAK packets in the standard.
RS232 didn't have packets. It had wires. It didn't have ACK/NACK either. It had CTS/RTS and DCR/DTR. There were some secondary signals (STD, SRD etc) that were rarely implemented after 1980.
>If anything, this is nothing more than an industry standards issue.
Get IEEE 802 to do it.
You'd be able to pass your medical records through an 802.1D compliant bridge transparently, with or without Q.
it is against the law to transport it across state lines though
Does it or its owner become suddenly more dangerous after crossing a state line?
And that's all they've ever been - a feel-good measure that accomplishes nothing....
So they are the same as the 2nd Amendment, yes?
Let's be clear about this: widespread gun ownership in the US is held to be useful for two purposes:
1) empowering the people to overthrow a tyrannical government
2) personal protection.
The second of these is overwhelmingly what the gun lobby focuses on when selling guns to their "patriotic American" base.
The problem is: widespread firearms ownership is demonstrably, empirically, a terrible solution to the problem of personal protection. Firearms for personal protection--specifically handguns--are vastly more widespread in the US than in any other developed nation. The murder rate in the US is vastly higher than any other developed nation.
So anyone looking at the data would have to say that widespread handgun ownership is "a feel-good measure that accomplishes nothing". Anything else would be simply bizarre, a complete rejection of the data. (http://en.wikipedia.org/wiki/List_of_countries_by_firearm-related_death_rate).
Please note: I am not arguing that the 2nd Amendment doesn't protect American's right to keep and bear arms, including handguns, AR-15s, etc. I am arguing--pointing out, really--that a very significant proportion of advertising, promotion and rhetoric around gun ownership in the US is aimed at exactly the kind of feel-good emotionalism that gun owners frequently complain about with regard to people who promote solutions to the problem of personal protection that have actually worked everywhere else in the developed world.
The 2nd Amendment and other features of the uniquely broken American political system prevents those solutions--gun control and the rule of law--from being applied in the US, but to pretend that is anything other than a tragedy that is indirectly responsible for the deaths of thousands of innocents every year is laughable.
Better solutions than guns exist to the problem of personal protection. Only in America are those solutions incapable of being implemented.
I just tried and successfully passed the variable "_BASH_FUNC_thingy" with the value "my_attack" through my apache web server to a CGI script using a url entered into a browser.
No, you get something like QUERY_STRING="_BASH_FUNC_thingy=my_attack", which is harmless because function definitions inside QUERY_STRING are not being evaluated after the last update.
No I didn't. I'll play with bash versions and see if there was a change. I don't think so though.
I have lived the ASN.1 horror. I will kill it. I will show no mercy. Know this, for it is true.
I would imagine that this will be the kind of a movie that will be in the five dollar bin at Walmart's within a month of release. And there will be a lot of them that simply stay in that bin.
At least they'll be neatly packed.
They will try to put CALEA crap in by default with no option to turn off.
But jar jars blink.
Fortunately for the evil doers, they don't have to be bound by past vulnerabilities.
Just give it a name that the script already uses.
If the script uses functions passed through the environment variables, it is now going to be written such that those variable names are prefixed with _BASH_FUNC_ because the new changes require it. So the attacker follows suit. The point being that the attacker can indeed modify the name and he or she or it can modify it to suit the script being attacked.
The underlying problem is using environment variables (I.E. data) that get executed by the interpreter. Don't do that. You can write CGI programs that are invulnerable, but you can't be sure every CGI program in every bit is system and web bloatware is invulnerable.
Better to fix CGI. Give it a new interface. E.G. It calls the program and hands it a pointer to a file that contains the variables. Or uses any other form of IPC. Just make sure it can't get executed unless intentionally by the idiot writing the receiving end.