More seriously, there are some CIX folks on NLZero and they've been tweaking their GUI front end to work with it (current CoSy). Beyond that it's been a long time since I (briefly) signed on to CIX so I can't really say. (There's also a Japanese version, MIX, originally (and still?) sponsored by Nikkei Byte magazine. The software was also installed at several universities.)
The copyright holder often stops distributing the work before the copyright term is up.
Quite true, especially in the case of print media (books, etc), (and old TV shows). The key point here (which some other posters miss) is that the author is not necessarily the copyright holder.
Too many new authors naively sign over "all rights" (or even just "all book rights") to the publisher and are then out of luck if the publisher lets the work go out of print. Savvy authors will insist on a "reversion of rights" clause in the contract, to the effect that if the book goes out of print for a certain specified length of time, the rights revert to the author who is then free to shop the book around to a different publisher.
In the case of works for hire or corporate authorship, when there is no readily identified individual author(s), it would make sense to have some similar "reversion of rights" clause in copyright law -- if you don't make the work available for some period of years, the copyright lapses. This was the idea behind renewal of copyright, I think. Sure, the publisher can get around that by doing a limited press run every few years, if that's worth it to them. If not, then they shouldn't have a problem with letting the copyright expire.
While I wouldn't have chosen your examples, I agree with your point.
An example closer to home: 20 years ago I wrote the original CoSy software used by, among others, the BIX conferencing system. The original copyright was held by University of Guelph, they later sold (some?) rights to a company called SoftWords. When BIX eventually closed up shop, a number of Bixen wanted to keep up the community on their own CoSy system. SoftWords hadn't been selling the software in some years, but an appeal to both U of G and SoftWords got them to agree to release CoSy under the GPL.
Problem was, neither of them had a readily available copy of the source nor were they inclined to spend much effort digging for it.
Fortunately, I still had a copy (ancient but readable), and the project lives on on Sourceforge. (The "son of BIX" lives on as Noise Level Zero, nlzero.com).
But what if Softwords had gone out of business, the assets dissipated and nobody even knew who had the rights to the software anymore? (Hmm, sounds a bit like Unix in some ways). That's certainly abandonware, but under the current law it wouldn't be public domain for another 75 or so years.
The Apollo 1 fire had nothing to do with spaceflight. That was a damn stupid pressure (and plugs-out) test at 16 PSI pure oxygen atmosphere, contrary to the manufacturer's recommendations (the fire safety guidelines were written for the 3 PSI O2 atmosphere used in flight).
Both Soyuz mishaps were on reentry, one with a leaky valve and one with a parachute malfunction.
Come to that, both Shuttle accidents were either on launch or reentry.
Nothing dangerous about spaceflight, it's getting there and back that's the bitch.
The Saturn V (on Apollo 12) certainly had an incident in flight: it was struck by lightning shortly after launch.
It's a tribute to the designers of the systems and the quick reactions of Pete Conrad and the rest of the crew that they managed to fly it to orbit where they reset the systems that had been offlined by the power surge.
NASA rewrote the guidelines about launching near/ through clouds after that one.
No they couldn't. There wasn't another vehicle available.
Actually there was. The next Shuttle mission was being prepped for a launch a month later. If the situation had been observed and understood, Columbia could have gone into a reduced consumption mode to stretch out time on orbit, and preparations for the next launch could have been stepped up (skip the payload, etc).
The management failure was that they didn't even look.
Those were, of course, merely examples. The closest I've come to Brainfsck is reading stuff on the web, and somewhere around I think I have the Coral66 reference.
Then there's the guy I worked with who should have put "Team Lead" on his resume. Pronounced "led", as in sinker or dead weight...
Now I could email you a.tar.gz file (which preserves permissions) containing a setuid-root shell script
Actually that wouldn't work either. Tar (at least, GNU tar) modifies ownership of files in the tarball owned by root (unless root's doing the extracion), and 'sh' seems to ignore the SUID bit on scripts owned by root.
I've seen some people do a skills matrix -- list each language (or other computer related skill, like system administration or particular packages) and give a level of experience for each, sometimes also with a "last used" date.
I used to categorize them in groups, something like: Highly skilled in: C, C++, Java Experience in: Python, PL/SQL Some exposure to: Ruby, Coral 66, BF
If I'd just done a couple of classes, it'd be in the "some exposure to" category. Anything less I wouldn't bother mentioning. (Hey, I've done the equivalent of "hello world" in a lot of obscure languages, and (like a lot of programmers) I can read more than I can write code in.)
These days I have enough trouble cramming my resume into just three pages, so I don't bother listing anything I'm not prepared (by both knowledge and inclination) to immediately sit down and start coding in. If there's some other language that might also be relevant to the job, I'll mention it in the cover letter. And there's stuff I leave out -- I've been an APL resident expert, even taught courses in it, but I don't mention it on my resume because (a) I'm very rusty and (b) I have no particular desire to do develop in APL again (and I guess (c), there's no demand for it). Now, if someone were looking to convert an APL application to Java, say, I might be interested.
(And on one job, despite never having claimed any knowledge of COBOL and even actively denying any knowledge of it, the boss stuck me with extending a COBOL application, over my protests, saying "it's easy, you'll pick it up". (Fortunately I managed to put it right back down again after that project;-)
I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.
Close but not quite. You're as likely to find that they end up using whatever new language you throw at them as if it were some weird dialect of the only one they know well.
My rule of thumb if I'm looking for someone that needs to be able to pick up a new language is to find someone that knows at least three different ones (and I wouldn't count C++, Java and C# as three -- one and a half, maybe), or two if they're different enough.
My first two computer languages were Algol and APL, I've since been paid to write programs in about a dozen other languages and written toy programs in another ten or so. Heck, except for short term contract jobs, I've often ended up developing software in some language other than the one I was originally hired for.
It's tough being on the hiring end too -- if I've got project deadlines looming and I'm given a foot-high stack of resumes to look through to pick out a few candidates to interview, I'm sorry but my first pass through the stack is to going to be to find any reason at all to not look at a given resume any further, so I can shrink the pile that I actually have to read and think about. I may end up throwing out a gem but as long as there's still one left in the pile I look at, that doesn't matter. (Well, not to me, I know it matters to the one I threw out.)
Yeah, the whole resume/HR/interview process sucks, and it's one of the least efficient ways to find a job (or a good candidate), but alas most tech types are even worse at social networking, at least with the kind of people one needs to to get the job.
Warning, before someone moderates the parent as "informative", be aware that the above is a semi-clever troll.
For example, the last paragraph about the kinetic energy of neutrons and whether you want fast or slow neutrons for a bomb or reactor is complete bullshit. A given nucleus has an optimum range of energy for neutron absorption, whether that nucleus is in a bomb or a reactor.
Further, breeding and/or refining nuclear fuel is not an exact process -- you're going to get quanties of other elements and isotopes according to the amount of fission, neutron capture and impurities in the original material -- the analysis will look at things like strontium, gadolinium, other fission byproducts and their isotopic ratios.
And yes, they really can determine which reactor the material came from. (Although determining *what part* of the reactor it came from, as suggested in a Tom Clancy book, is a stretch).
Plutonium is a normal byproduct of uranium reactor operation, particularly of the unenriched uranium heavy water moderated reactors of the CANDU style, it doesn't have to particularly be from a special breeder reactor. The latter is simply more efficient. Analysis of the residue will clear distinguish them.
More interesting, has anyone ever had to wait for a turbolift?
As a matter of fact, yes. I recall Kirk & Spock in one episode waiting for one. Sorry, don't recall which ep, I'm not that much of a Trekkie.
(In, I think, "Wrath of Khan", there's also a scene where the occupants of the lift pause it to talk -- when it finally arrives at destination McCoy is there waiting muttering something about "who's holding up the damn elevator?". Dang, maybe I am that much of a Trekkie....)
Skylab was going slower, but not 100 times slower.
Typical meteor speed is on the order of 40,000 MPH. Typical orbital velocity (Skylab) is about 18,000 MPH. Skylab was going about 1/2 the speed -- 100 times slower would be subsonic.
(Moderators should only moderate "informative" unless they know for a fact that the the information is indeed correct. There should also be a (-1, factually wrong) moderation. Sigh)
It'd be like nuclear detonations, only without the radiation.
Oh, from an explosion like that, you'll get radiation -- X rays and such from the high temperature plasma. Just not us much radiation (no neutrons) as from a nuke, and no fallout. (Well, not radioactive fallout. Plenty of dust.)
When they break up at altitude they slow down faster -- increased drag-to-mass ratio on the pieces. (Also, the force of any explosive break up will slow down the rearward pieces, but speed up forward pieces.) A grapefruit sized piece will slow down quite a bit (maybe even to its terminal velocity), with something larger it'll depend on the shape and composition. Of course, a hundred foot siderite (nickel iron) won't slow down hardly at all.
It also depends on the angle -- straight down is statistically improbable, and an angular approache will give it more time in atmosphere just due to geometry and maybe a little from aerodynamic lift.
(At a very shallow angle, it could just "bounce off" the atmosphere. Such an incident was fortuitously recorded on film (or video) some years ago over the northwest, the estimated size of the rock was "about as big as a locomotive", it entered the atmosphere enough to leave a trail and then skipped/bounced out into space again.)
Consider how much of the Shuttle Columbia (or for older folks, Skylab) hit the surface. Granted, that was protected part of the way by shielding (Skylab wasn't) and only entered at about half the speed of a typical meteorite, but it gives you an idea. (Higher speed means more energy to heat up the rock, but also less time to do it in before the rock hits the ground.)
The stuff that burns up completely in the upper atmosphere is dust to sand size.
(Or just watch the opening credits of "Smallville";-)
The other point I guess is that it's only 100 ft across (why not 30m ?) so it would have burnt up on entry into the atmosphere,
Uh, no. Even 1 ft across wouldn't completely burn up on entry into the atmosphere (but would either break into small pieces or otherwise slow down enough to be mostly harmless).
Depending on the composition -- mostly ice, mostly rock or mostly nickel-iron -- it would either completely detonate at altitude -- like the Tunguska explosion in Siberia early last century -- or plow into the ground and detonate. Meteor Crater in Arizona, nearly a mile wide, was formed by a nickel-iron meteor only a bit bigger than this one. (150 ft vs 100 ft, so maybe it would only dig a crater a half mile wide and 300 feet deep.)
About equivalent to a largish H-bomb. Not that big a deal if you're more than fifty miles or so away, unpleasant otherwise.
If we caught a large animal, in the absence of cutting tools, such as stone knives, we'd be reduced to gnawing at its shins and ankles.
Ah, but we (and our close but extinct cousin species) have been using tools for much longer than our faces have been flat. Granted, even great apes don't have much of a 'muzzle' compared to dedicated predators, but it's sufficient to get the job done -- especially since we (primates in general) have strong enough hands we can pinch up a fold of flesh to tear into. Felines and canines don't.
Of course, we're not talking Cape Buffalo, more like deer and antelope, which are more delicately built -- they're built to run away, not just stand there looking intimidating -- and by a strange coincidence, we're built to run down animals that run away.
(BTW, your point about just throwing stones: there's some speculation that the crudest stone tools often called "hand axes" are in fact more like stone frisbees with a sharp edge, in that they'd perhaps be more effective if thrown than if hand wielded.)
Slashdot Mirror
Cheers!
And, you're welcome.
Well, it's ancestral to it ;-)
More seriously, there are some CIX folks on NLZero and they've been tweaking their GUI front end to work with it (current CoSy). Beyond that it's been a long time since I (briefly) signed on to CIX so I can't really say. (There's also a Japanese version, MIX, originally (and still?) sponsored by Nikkei Byte magazine. The software was also installed at several universities.)
The copyright holder often stops distributing the work before the copyright term is up.
Quite true, especially in the case of print media (books, etc), (and old TV shows). The key point here (which some other posters miss) is that the author is not necessarily the copyright holder.
Too many new authors naively sign over "all rights" (or even just "all book rights") to the publisher and are then out of luck if the publisher lets the work go out of print. Savvy authors will insist on a "reversion of rights" clause in the contract, to the effect that if the book goes out of print for a certain specified length of time, the rights revert to the author who is then free to shop the book around to a different publisher.
In the case of works for hire or corporate authorship, when there is no readily identified individual author(s), it would make sense to have some similar "reversion of rights" clause in copyright law -- if you don't make the work available for some period of years, the copyright lapses. This was the idea behind renewal of copyright, I think. Sure, the publisher can get around that by doing a limited press run every few years, if that's worth it to them. If not, then they shouldn't have a problem with letting the copyright expire.
While I wouldn't have chosen your examples, I agree with your point.
An example closer to home: 20 years ago I wrote the original CoSy software used by, among others, the BIX conferencing system. The original copyright was held by University of Guelph, they later sold (some?) rights to a company called SoftWords. When BIX eventually closed up shop, a number of Bixen wanted to keep up the community on their own CoSy system. SoftWords hadn't been selling the software in some years, but an appeal to both U of G and SoftWords got them to agree to release CoSy under the GPL.
Problem was, neither of them had a readily available copy of the source nor were they inclined to spend much effort digging for it.
Fortunately, I still had a copy (ancient but readable), and the project lives on on Sourceforge. (The "son of BIX" lives on as Noise Level Zero, nlzero.com).
But what if Softwords had gone out of business, the assets dissipated and nobody even knew who had the rights to the software anymore? (Hmm, sounds a bit like Unix in some ways). That's certainly abandonware, but under the current law it wouldn't be public domain for another 75 or so years.
Clearly, you've never been to Saskatchewan.
Yeah. Think Kansas, only much bigger and (believe it or not) flatter.
Hey, isn't Smallville in Kansas? What is it with meteorites and flat places (see also Meteor Crater, Arizona) anyway?
The Apollo 1 fire had nothing to do with spaceflight. That was a damn stupid pressure (and plugs-out) test at 16 PSI pure oxygen atmosphere, contrary to the manufacturer's recommendations (the fire safety guidelines were written for the 3 PSI O2 atmosphere used in flight).
Both Soyuz mishaps were on reentry, one with a leaky valve and one with a parachute malfunction.
Come to that, both Shuttle accidents were either on launch or reentry.
Nothing dangerous about spaceflight, it's getting there and back that's the bitch.
The Saturn V (on Apollo 12) certainly had an incident in flight: it was struck by lightning shortly after launch.
It's a tribute to the designers of the systems and the quick reactions of Pete Conrad and the rest of the crew that they managed to fly it to orbit where they reset the systems that had been offlined by the power surge.
NASA rewrote the guidelines about launching near/ through clouds after that one.
No they couldn't. There wasn't another vehicle available.
Actually there was. The next Shuttle mission was being prepped for a launch a month later. If the situation had been observed and understood, Columbia could have gone into a reduced consumption mode to stretch out time on orbit, and preparations for the next launch could have been stepped up (skip the payload, etc).
The management failure was that they didn't even look.
Heh!
Those were, of course, merely examples. The closest I've come to Brainfsck is reading stuff on the web, and somewhere around I think I have the Coral66 reference.
Then there's the guy I worked with who should have put "Team Lead" on his resume. Pronounced "led", as in sinker or dead weight...
Now I could email you a .tar.gz file (which preserves permissions) containing a setuid-root shell script
Actually that wouldn't work either. Tar (at least, GNU tar) modifies ownership of files in the tarball owned by root (unless root's doing the extracion), and 'sh' seems to ignore the SUID bit on scripts owned by root.
I've seen some people do a skills matrix -- list each language (or other computer related skill, like system administration or particular packages) and give a level of experience for each, sometimes also with a "last used" date.
;-)
I used to categorize them in groups, something like:
Highly skilled in: C, C++, Java
Experience in: Python, PL/SQL
Some exposure to: Ruby, Coral 66, BF
If I'd just done a couple of classes, it'd be in the "some exposure to" category. Anything less I wouldn't bother mentioning. (Hey, I've done the equivalent of "hello world" in a lot of obscure languages, and (like a lot of programmers) I can read more than I can write code in.)
These days I have enough trouble cramming my resume into just three pages, so I don't bother listing anything I'm not prepared (by both knowledge and inclination) to immediately sit down and start coding in. If there's some other language that might also be relevant to the job, I'll mention it in the cover letter. And there's stuff I leave out -- I've been an APL resident expert, even taught courses in it, but I don't mention it on my resume because (a) I'm very rusty and (b) I have no particular desire to do develop in APL again (and I guess (c), there's no demand for it). Now, if someone were looking to convert an APL application to Java, say, I might be interested.
(And on one job, despite never having claimed any knowledge of COBOL and even actively denying any knowledge of it, the boss stuck me with extending a COBOL application, over my protests, saying "it's easy, you'll pick it up". (Fortunately I managed to put it right back down again after that project
I figure that anyone sharp enough to have picked up one language and set of libraries and used it well can just as well do it again.
Close but not quite. You're as likely to find that they end up using whatever new language you throw at them as if it were some weird dialect of the only one they know well.
My rule of thumb if I'm looking for someone that needs to be able to pick up a new language is to find someone that knows at least three different ones (and I wouldn't count C++, Java and C# as three -- one and a half, maybe), or two if they're different enough.
My first two computer languages were Algol and APL, I've since been paid to write programs in about a dozen other languages and written toy programs in another ten or so. Heck, except for short term contract jobs, I've often ended up developing software in some language other than the one I was originally hired for.
It's tough being on the hiring end too -- if I've got project deadlines looming and I'm given a foot-high stack of resumes to look through to pick out a few candidates to interview, I'm sorry but my first pass through the stack is to going to be to find any reason at all to not look at a given resume any further, so I can shrink the pile that I actually have to read and think about. I may end up throwing out a gem but as long as there's still one left in the pile I look at, that doesn't matter. (Well, not to me, I know it matters to the one I threw out.)
Yeah, the whole resume/HR/interview process sucks, and it's one of the least efficient ways to find a job (or a good candidate), but alas most tech types are even worse at social networking, at least with the kind of people one needs to to get the job.
Warning, before someone moderates the parent as "informative", be aware that the above is a semi-clever troll.
For example, the last paragraph about the kinetic energy of neutrons and whether you want fast or slow neutrons for a bomb or reactor is complete bullshit. A given nucleus has an optimum range of energy for neutron absorption, whether that nucleus is in a bomb or a reactor.
Further, breeding and/or refining nuclear fuel is not an exact process -- you're going to get quanties of other elements and isotopes according to the amount of fission, neutron capture and impurities in the original material -- the analysis will look at things like strontium, gadolinium, other fission byproducts and their isotopic ratios.
And yes, they really can determine which reactor the material came from. (Although determining *what part* of the reactor it came from, as suggested in a Tom Clancy book, is a stretch).
Plutonium is a normal byproduct of uranium reactor operation, particularly of the unenriched uranium heavy water moderated reactors of the CANDU style, it doesn't have to particularly be from a special breeder reactor. The latter is simply more efficient. Analysis of the residue will clear distinguish them.
You can add Limbaugh and Bush's IQs together and it couldn't boil water.
Well, duh! You've got a units mismatch. At what IQ does water boil?
The level of scientific illiteracy in this country these days.... sigh.
Of course TiVo is dying. The silly thing is based on BSD. Oh, wait...
Now there's a show I'd like to see in a DVD boxed set.
OTOH, after watching a few of them again this many years later, I might come to regret the purchase.
GPS would be silly. Just triangulate the signal source as received by several different APs. That'd be more accurate, too.
More interesting, has anyone ever had to wait for a turbolift?
As a matter of fact, yes. I recall Kirk & Spock in one episode waiting for one. Sorry, don't recall which ep, I'm not that much of a Trekkie.
(In, I think, "Wrath of Khan", there's also a scene where the occupants of the lift pause it to talk -- when it finally arrives at destination McCoy is there waiting muttering something about "who's holding up the damn elevator?". Dang, maybe I am that much of a Trekkie....)
50% wider and roughly twice the mass of the one detected
;-)
If both bodies were the same shape the larger would have eight times the volume.
Er, 1.5^3 = 3.375, not eight. Other than that you're doing fine
Skylab was going slower, but not 100 times slower.
Typical meteor speed is on the order of 40,000 MPH. Typical orbital velocity (Skylab) is about 18,000 MPH. Skylab was going about 1/2 the speed -- 100 times slower would be subsonic.
(Moderators should only moderate "informative" unless they know for a fact that the the information is indeed correct. There should also be a (-1, factually wrong) moderation. Sigh)
It'd be like nuclear detonations, only without the radiation.
Oh, from an explosion like that, you'll get radiation -- X rays and such from the high temperature plasma. Just not us much radiation (no neutrons) as from a nuke, and no fallout. (Well, not radioactive fallout. Plenty of dust.)
When they break up at altitude they slow down faster -- increased drag-to-mass ratio on the pieces. (Also, the force of any explosive break up will slow down the rearward pieces, but speed up forward pieces.) A grapefruit sized piece will slow down quite a bit (maybe even to its terminal velocity), with something larger it'll depend on the shape and composition. Of course, a hundred foot siderite (nickel iron) won't slow down hardly at all.
It also depends on the angle -- straight down is statistically improbable, and an angular approache will give it more time in atmosphere just due to geometry and maybe a little from aerodynamic lift.
(At a very shallow angle, it could just "bounce off" the atmosphere. Such an incident was fortuitously recorded on film (or video) some years ago over the northwest, the estimated size of the rock was "about as big as a locomotive", it entered the atmosphere enough to leave a trail and then skipped/bounced out into space again.)
Consider how much of the Shuttle Columbia (or for older folks, Skylab) hit the surface. Granted, that was protected part of the way by shielding (Skylab wasn't) and only entered at about half the speed of a typical meteorite, but it gives you an idea. (Higher speed means more energy to heat up the rock, but also less time to do it in before the rock hits the ground.)
;-)
The stuff that burns up completely in the upper atmosphere is dust to sand size.
(Or just watch the opening credits of "Smallville"
The other point I guess is that it's only 100 ft across (why not 30m ?) so it would have burnt up on entry into the atmosphere,
Uh, no. Even 1 ft across wouldn't completely burn up on entry into the atmosphere (but would either break into small pieces or otherwise slow down enough to be mostly harmless).
Depending on the composition -- mostly ice, mostly rock or mostly nickel-iron -- it would either completely detonate at altitude -- like the Tunguska explosion in Siberia early last century -- or plow into the ground and detonate. Meteor Crater in Arizona, nearly a mile wide, was formed by a nickel-iron meteor only a bit bigger than this one. (150 ft vs 100 ft, so maybe it would only dig a crater a half mile wide and 300 feet deep.)
About equivalent to a largish H-bomb. Not that big a deal if you're more than fifty miles or so away, unpleasant otherwise.
If we caught a large animal, in the absence of cutting tools, such as stone knives, we'd be reduced to gnawing at its shins and ankles.
Ah, but we (and our close but extinct cousin species) have been using tools for much longer than our faces have been flat. Granted, even great apes don't have much of a 'muzzle' compared to dedicated predators, but it's sufficient to get the job done -- especially since we (primates in general) have strong enough hands we can pinch up a fold of flesh to tear into. Felines and canines don't.
Of course, we're not talking Cape Buffalo, more like deer and antelope, which are more delicately built -- they're built to run away, not just stand there looking intimidating -- and by a strange coincidence, we're built to run down animals that run away.
(BTW, your point about just throwing stones: there's some speculation that the crudest stone tools often called "hand axes" are in fact more like stone frisbees with a sharp edge, in that they'd perhaps be more effective if thrown than if hand wielded.)