You have just picked a fight with an 800lb gorilla; you are not going to win. IBM will trot out a few thousand patents that you infringe upon, game over.
Except that SCO has the advantage that it can stop producing any products (since this suit will probably ruin its own markets), while Linux is becoming a significant presence in IBMs offerings.
If you make the (probably unjustified) assumption that both companies have valid and infringed upon patents, then after trading off penalties for past behaviour (likely to wind up as a negligible dollar amount due to infringement both ways) then SCO could discontinue it's products (and thus have no need of a license) while IBM would still want to ship Linux, and SCO would get the license fees.
But more to the point is that SCO seems to be claiming that IBM coders couldn't have developed an efficient X86 scheduler - despite the fact that IBM has been writing schedulers for various platforms for decades, and the Linux scheduler is platform agnostic (and IBM contributions may well have had far more influence from running in partitions on IBM mainframe machines).
Not quite. Rambus Ink. (to steal a phrase from el Reg.), doesn't actually make any chips themselves. They make their money by licensing their patents for their serial RDRAM design, and by e\x\t\o\r\t\i\o\n\ licensing (questionably acquired) patents applied to synchronous DRAM.
They would be better off writing a new OS that had lighter requirements...
'Lighter requirements' is a pretty hard to define goal - contrary to many opinions, a Linux kernel configured to have only those functions that are needed for a specific application is pretty close to the smallest size that I've ever seen those functions implemented in. (At one time gcc did not optimize well, making even a simple embedded operating environment written in and for C much bigger than one hand-crafted in assembler - but now that embedded apps are getting more complex, most embedded systems are compiled with a flavour of gcc, so that's no longer relevant)
For a TCP/IP enabled fridge magnet, you could write an application that would parse only those network packets that it was designed to handle and ignore the rest (and build and send only those packets that it needed to know about) but unless you have some programmers who are really skilled with TCP/IP,it undoubtedly costs less to just use a well developed general purpose stack such as Linux.
The per unit cost of slightly more memory/cpu power even for millions of units is still probably less than the amortized development costs (even without time-to-market costs that could be saved with an off-the-shelf stack), especially when there's no per unit cost for the OS - After all most embedded RTOS vendors charge a per unit license fee.
There is very little in the Linux kernel that can't be stripped out of a custom build if it isn't needed - and for an embedded device, that leaves very little overhead. On the other hand, nobody really wants to have to write custom drivers for standard components such as a USB hub. I tend to think of Linux as a toolkit that you can pick and choose from. It seems the embedded developers have a similar view, with the additional ability for applications to query to see what was chosen.
....and a design to allow it to meet hard real time deadlines
Ok, SET/.MODE=RANT
I'm just about fed up with hearing blanket statements that some flavour of Unix/Linux etc. can't do hard real time without specifying (or probably even knowing) just what needs to be run as 'hard real time'. I've implemented many small, special purpose industrial systems over the years, and most of the ones that I have had to deal with had 'hard real time' requirements in the tens of microseconds range, and I've used some flavour of *nix for implementing such systems ever since Xenix on the 286 became available.
The things that Linux can't do is to guarantee that a user-space application will be able to respond to an external stimulus in some small number of microseconds, or will be able to access slow shared resources in some small number of milliseconds.
So what? By most definitions of 'hard real time' then even reading data from a serial line is a 'hard real time' application in itself - if you don't read the character before the next character arrives (or the buffer fills for modern chips) it will be lost - this is a 'hard real time deadline' but nobody questions Linux's ability to do this. You don't need an actual application to buffer each individual character though, This is done by the kernel driver i.e. in the interrupt handler.
Even with old minicomputer real-time operating systems (specifically Digital RT11) the OS couldn't keep up to sub-millisecond deadlines, so I wrote device driver routines to do the 'hard real time' functions.
Moving to *nix systems simply kept the necessity of a device driver to handle the 'hard real time' part of the application.
Similarly, for a lot of 'fridge magnet' applications, you don't need that high a level of real time application support - just a kernel driver for the actual physical I/O applications.
With a pre-emptable kernel, and NO USER APPLICATIONS, just the device's linux appplication code for things like a UI, TCP/IP stack and similar $20 device requirements, application response times can still be guaranteed within fractions of a millsecond.
Only when you get into systems with things such as user supplied apps (i.e. causes unpredictable running conditions) or resource contention (such as needing to prioritize file access on a slow device) does the application response time become unpredictable, and for the scale of many embedded (and even non-embedded) applications this is not a problem.
Very few applications (as opposed to device drivers) need sub-millisecond response anyway. Consider that when a human is involved in the loop, anything less than about 10 milliseconds of lag is not discernable. Despite the observation in software testing (and other things) that errors predicted to occur once in a million times tend to happen 9 times out of 10 (because there is no real 'random choice' in most software), absolute timing guarantees are not often needed. But 'soft real time' capability is a necessity for any UI to be usable. I'd be unable to type this if Linux couldn't do at least that much.
On the other hand, I've had to work with some 'hard real time' systems that guarantee absolute worst case 100 millisecond response - but cannot under any circumstance respond any faster than that!
But actually reading the law : IANAL, therefore my opinion isn't worth sh*t on that, there is nothing that gives the copyright holder permission to defeat the technological measure in order to force access to the copyright holder's work when it is controlling access to other copyright holders works - and the technological measure in this case still meets the rest of the definition.
As far as I can tell the authority of the copyright owner only extends to the content of the message (the spam itself), not to the the technological measure.
Unless the spammer has copyright to all of the mail that is arriving, he is still bypassing that protection, and does NOT have the authority of the copyright owners.
It may even be arguable that the spam is bypassing the protections and modifying (by adding his spam to the incoming mail) the context of other copyrighted works.
I'd certainly consider that any spam that got past my spam filters is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title; said protected work being the compilation of the desirable (and copyrighted) messages.
It only applies to the specific case of circumventing access controls for copyrighted works, and there are clearly no copyrighted works involved here
Well, since the email written by the spammer is techically copyright by the spammer, and the spamassasin or equivalent is a technical means for blocking access to that copyrighted work, then it seems that it would be illegal to circumvent that measure. I don't recall seeing anything in the DMCA that exempts the copyright holder from the ban against circumventing the technology.
This article also points out the unfortunate fact that when the comet is at it's brightest, it will be directly on the opposite side of the sun, and impossible to observe from the Earth.
As a competent evil overlord, I will NOT create fearless troops. Troops that are fearless will not be afraid to try to overthrow ME. -- Note - any henchman that thinks that this is insightful instead of funny is reading too much into it, and should be immediately sent for a session with my new zombification system.
While setting up honeypot addresses in itself seems to be a good idea, I suspect that it would be a good idea to be sure that any item to which the address is attached or displayed carries the notice you mention - by sending to that email address the spammer grants publication rights to the Great Spam Archive - so that there can be no accusation that there was no way for them to know about it before they sent the message.
For that matter, it might be worthwhile to add a rider to the notice something along the (properly translated to legalese) line of: "Also, by sending to this address, the sender agrees to pay an archiving fee of $500 per item." If they claim copyright, then you know who to claim the archiving fee from:). (I wonder if the disclaimer could mandate a $100,000 item removal fee?)
It seems that various spamhaus operators are a litigious bunch. They have regularly sued blackhole lists claiming their spam to be legal, even though at least one Australian case was thrown out of court. And it seems as though for every actual threatening letter sent by an actual lawyer, it seems they send about a dozen (or more) that clearly are not.
As it happens, this particular case appears to be one of the latter. It costs them nothing to try, but it costs the recipient time in making the distinction. Typical for spam.
I don't know where the physical location of the spam archive is, but if it is located in a jurisdiction that actually has some meaningful anti-spam laws, then chances are good that the referenced 'copyright' spam is illegal - in which case claiming copyright should allow an immediate countersuit (by a real lawyer, even) since the identity of the party responsible for sending it is now firmly established.
( I can't resist joking: Nobody expected this spammish imposition.)
RFI chokes are NOT simple magnets (nor are they permanently magnetized like a magnet).
What they are is a ferrite core that makes a complete closed loop around the cable. Radio frequencies currents can't go through the middle - it blocks high frequencies. (If you want to get technical, the radio frequency current induces a magnetic field in the choke, and the change in magnetic field induces a voltage that exactly opposes the current.)
While strip magnets are made from a similar material, you simply cannot make it as effective as a proper choke.
On the other hand, the original question mentions hum - presumably AC 60Hz - and a choke will have negligible effect on a frequency that low.
If it's a lighter weight implementation of the Mo-zilla browser, wouldn't that make it Lesszilla?:)
Re:Didn't these things have selectable word sizes?
on
Bringing Back the PDP8
·
· Score: 1
I think you may have been the unwitting victim of a fairly common joke that occasionally was pulled on the innocent visitors when I was working in a university computer lab in the early 70s.
The lab had a PDP8M that was the controller for a prototype communications network between quite dissimilar computers. Due to the data sizes involved, the program counter register would have all it's bits flickering, but the accumulator would only have 8 bits flickering (it was exclusively handling octets of data all the time) and one other register - index? - I forget now - would only have 4 bits flickering (because this prototype network only had 4 nodes, numerically 1, 2, 4 and 8, so we could see the pattern in the lights to tell which nodes were using the network).
So we used to tell visitors who didn't know better that the switch changed the word length from 4 bits to 8 bits to 12 bits, and we left it on 12 bits because it was obviously faster (the program counter changed faster than the other two as well.... and the machine was slow enough that you could see the difference.)
Well, if you make the reasonable assumption that such strangelets are NOT generated in the solar system, then there is a minimum speed (somewhere in the ballpark of 50 Km/s) that is determined by the combined escape velocities of the earth and sun. Anything coming from interstellar space out of the planetary plane canno arrive traveling slower than this. Anything much over 10000 Km/s is probably not going to be detectable as 'traveling' by the researchers' criteria, because it will seem instantaneous (i.e. less than a second - how well are the clocks calibrated?) to the relatively sluggish seismic monitors. So that would be the range they would be able to look for traces in.
Then they find a trace, and the speed is then measured (using the time delay in the seismic record) to get the speed of 400 Km/s - and the above figures just sanity check this as a plausible value.
> In interstellar space, they would be the strongest local gravity source,
A cell-sized chunk of this is only 1 ton, so it would have no greater gravity field than a 1-ton rock hurtling through interstellar space.
A tonne of matter where there's little gravity gradient, i.e. interstellar (or even intergalactic) space has enough gravity to capture a fair amount of matter over the course of a few billion years. Also, because the strangelet is physically minute, the inverse square part of the gravity equation means that gravity field is literally millions of times stronger near the strangelet than it is near the surface of a normal one-ton rock
The thing that's unique about an SQN is that when any material *does* get close enough to it to be captured by its gravity, if it ever gets near to touching the surface, it'll collapse all the way down into quark material itself, and be indistinguisable from the original material.
Only until the density (i.e. concentration) of strange quarks in the strangelet becomes too low compared to the total mass to overcome the instability.
It's neither proven nor even accepted that strange quarks can convert normal top and bottom quarks to strange quarks and continually grow such matter. While the strange quark is massive enough to provide sufficient energy to create many normal quarks, it is much less likely that a combination of quarks can generate a new strange quark. The expected numbers of strange, top, and bottom quarks in a strangelet are all approximately equal, so there would be an upper size limit on the mass that the strangelet itself can accumulate (until you get to the sizes and energies involved in the postulated quark stars, anyway.). As a matter of fact, it has been postulated that strangelets can actually evaporate by neutron emission, stimulated by relatively low speed collisions with air molecules.
Even if it did at some point have a little ball of gas around it, collisions between particles would virtually guarantee that, within a short time, nearly all the atoms would venture near the core, and be sucked in. So at most, one of these things would have a very tenous wisp of gas around it.
On the other hand, it could be a lump of ice with the strangelet at the center. It has also been suggested (and partly confirmed by observation of cosmic ray debris at high altitudes) that interaction cross section of a strangelet is MUCH smaller than that of a normal nucleus, let alone the size of a normal atom - such that it could actually sit between the atoms of an ice-ball without interacting with them.
These factors are a good thing, otherwise each strangelet that hit the earth would emerge MUCH heavier than it went in, and also, much slower, making it very likely to be captured by the earth (or at least the solar system) and thus would have converted us all into something... strange...(even by/. standards) by now.
>... could have had a multiple megaton blast associated with them, but there would be nothing at the surface to retain evidence...
There are satellites that are on the lookout for bright flashes of light like that; they would have seen it, if nothing else.
And how would it tell it apart from a meteorite burning up in the atmosphere? They HAVE seen these sorts of light flashes. See the article a little while back about there not being as many 'small' meteors (under 10 meters) as it was thought that there were. And the ones that could specifically detect what type of IR bloom it was (such as a nuclear event or a ballistic missile launch) are NOT focused on Antarctica.
I have to wonder if such strangelets could traverse stellar distances without accumulating a coating of hydrogen (and/or other) ice. In interstellar space, they would be the strongest local gravity source, and (especially if they have been accumulating since the big bang) be accompanied by quite a bit of material.
This could make for quite an explosion as that mass entered the atmosphere - my math is based on pure guesswork, but it seems that the combination of hydrogen ice, heated to a plasma in a shockwave, and the massive strangelet creates an extremely high local pressure and temperature. (Seems similar enough to the designs for mini-black-hole catalyzed fusion that it might even result in a fusion reaction - but I'll not speculate on that.)
The two entry points noted here - one was in barren antarctic land and the other in the uninhabited and infrequently traveled southern ocean - could have had a multiple megaton blast associated with them, but there would be nothing at the surface to retain evidence - no trees to be knocked down, nothing permanent to record the event, out of the scan area of most satellites, that even if there WAS an explosion, we would be unlikely to find any evidence.
Then again - I've already wondered elsewhere if this couldn't explain the Tunguska explosion.
It's pretty obvious that the article has the amount of time wrong. The suggestion of speed given by the article is that the particles might travel at about 400 Km/s, and this particular track apparently went in near a pole and came out near the equator - a rough guess (somebody else can do the actual spherical trig.) is 8500 Km of travel through the earth, and at 400 Km/s that's about 21 seconds, which is on the close order of the 27 seconds you noted from the map.
Now if it WAS.73 of a second, then the alleged particle was travelling close to 12,000 Km/s - 4% of lightspeed - I suspect that 400 Km/s is more in tune with both the energies (not) observed, and the (escape) velocity that could be imparted by falling into the solar system from interstellar space. (At least, either way, it sounds like this one won't be coming back.)
Unfortunately, the seismography data that is not associated with earthquakes stopped being collected by the USGS (or at least, is not archived) since 1993.
I suspect that funding an archive for this data would be far less expensive than the huge particle physics machines that are searching for similar matter:)
Not to mention - it might just be worth calculating the orbital path of the particles that were (or might be) detected, just to make sure that they aren't coming back. Given the energy they apparently release, this could even be an alternate explanation for the Tunguska explosion in Siberia. (Other than exploding meteorites that don't leave a crater, and a misfire of Tesla's Death Ray.)
Developer support for an OS such as Linux is more like "What? Are you a fucking idiot? RTFM asshole!"
Unfortunately, for much of the Open/Free software available, there is often no proper FM, only an out-of-date HOWTO. (After all, writing code is MUCH more personally rewarding and/or ego boosting than writing documentation.)
Thus the normal response for open source is not RTFM, but RTFS.
(And at least, the source is available - and often has the necessary documentation embedded in it.)
There is an annual minimum royalty of $500, which means that the smallest of small webcasters may not be able to afford it.
Umm... I think it's even worse than that.
I'm no expert at translating from legalese, but it sure seems that $500 is for past revenues, in 1998 - and there's a $2000 per year minimum after that, i.e. $6K for 1999, 2000, and 2001, and then another $2K minimum for 2002. And that's just to settle PAST broadcasts. So there's a minimum outlay of about $8500 for ANY webcaster that's been around for those years.
Even if a webcaster is non-profit, with no income, they want 5% of expenses - still subject to the minimums.
Oh, and you're a small webcaster until you make more than a $1.25 Million?
Except for the switch to liquid hydrogen, most liquid fuel rockets are descendants of the V-2. I mean it's not like it's rocket sci^w^w nuclear physics or anything.
I'm fairly certain that most rockets designed after the V2 used a combination of steerable main and/or auxilliary engines for control. This is actually a return to the V2 control system, using the same system of carbon vanes in the exhaust that the V2 used.
As aside, most of the 'Rocket science' complexity is actually done away with in this design. Simply having a fixed mount for the engine cuts out a LOT of complexity. And reducing the complexity will definitely reduce the cost.
PLEASE... look up methane hydrates. It's NOT methane soaked rock. FYI, that word "hydrates", has somehting to do with its nature.
Yeah, I did, before I posted. Everything I found indicated that it breaks down at sea level at any temperature above 270K - i.e. below freezing. Canada may be the great white north, but it's NOT that cold out by Vancouver island right now, nor has the ocean bottom temperature been near that there since shortly after the last ice age.
I did find, however, reference to porous rock structures saturated with methane hydrate, however, that keep the methane hydrate at just that slightly higher pressure needed, and that WILL burn as the methane hydrate within breaks down. There was also reference to such rocks indicating deeper oil and reserves.
So you really think that methane hydrates have little to do with methane hydrates??? For the love of...
Yeah, a story where people claim 'large reserves' and confuses '850 metres below the sea floor' with '850 metres below the surface', combined with the local temperatures, and the existence of porous rocks with methane hydrate in them. It's quite possible that the actual subject of the story has very little to do with large deposits of pure methane hydrate right on the sea floor. (Such relatively pure deposits exist - I'm just not sure of the CBC story about this one location.)
Just because the CBC has reported something doesn't mean that they got the story right. I can easily see a reporter - or anyone with second hand information and a little knowledge of methane hydrates - confusing the two possiblities.
The deposit of methane hydrate, or frozen gas, came to light early last month when a fishing crew pulled up a chunk of the material in their nets.
How could they pull a chunk of pure methane hydrate to the surface without it decomposing? It breaks down when you reduce the pressure.
It could be rocks saturated with methane, similar to those found under the North Sea - but if that's the case, the deposit itself is practically worthless (how much rock would have to be brought to the surface and crushed/heated/whatever in order to release the methane?)
More likely, these are just (again as in the North Sea) just an indicator that there are deeper reserves of oil and/or gas below the seafloor, and little to do with methane hydrates.
For that matter, althought he article says 'in about 850 metres of water', the text on the picture shows '850 metres below the ocean floor' - NOT the same thing.
Scientists dropped a pipe to the bottom, pumped up a little water, and as the water charged with carbon dioxide rose...it bubbled and pushed itself up and out of the top of the pipe.
Seems like this might be an effective method for extracting the methane, too. Just needs something at the bottom (like a dredge) to break off pieces of the hydrate/ice, with the pipe to suck them up to the surface. They revert to water and methane part way up, and the density change drives the flow in the pipe. Separate the gas bubbles from water at the top (or even just above the level that the ice changes state due to decreasing pressure to reduce the pipe strength neessary).
This might even have the effect of bringing deep nutrients to the surface and improving local fishing (sort of like the natural upwellings that support huge fish population in other areas).
Hmm. How soluble IS methane in low-pressure water? I seem to recall that some single-cell critters can eat methane - would they work as the basis of a food chain, perhaps?. It could be the basis for some intensive fish-farms, too.
On the other hand, though, I can't find any information on how pure the methane extracted might be - if it's got high sulphur content or other similar problems, it might not be quite as good a fuel as might have been hoped for - and could be even worse disolved in seawater.
Sorry, no. The mouse would have to scan the data for you, and the hardware just isn't capable of doing that. There's no way to change the way the mouse works with a driver
Well, the hardware in any optical mouse IS capable of doing this - it's the firmware to actually do it thats lacking - unfortunately, I don't think that any optical mouse's firmware is accessible for rewrite, even with a hardware hack - I presume that being unable to rewrite the firmware is what you mean by being unable to change the way the mouse works with the drivers.
If the firmware were rewritten by any means, though, the way that the mouse interacts with the driver wouldn't have to change, either - it would be sufficient to provide an extra 'button' signal (button 6 maybe - definitely not 'middle') that corresponds to whether the center of the sensor area last became lighter or darker.
The addition of such a 'button' singal would be sufficient for application software to determine the presence and content of any barcode - assuming that the user was able to move the correct portion of the mouse over a valid portion of the barcode.
Frankly, though, the easiest device to turn into a barcode scanner would be a simple top-of-the-monitor type webcam:)
Slashdot Mirror
Except that SCO has the advantage that it can stop producing any products (since this suit will probably ruin its own markets), while Linux is becoming a significant presence in IBMs offerings.
If you make the (probably unjustified) assumption that both companies have valid and infringed upon patents, then after trading off penalties for past behaviour (likely to wind up as a negligible dollar amount due to infringement both ways) then SCO could discontinue it's products (and thus have no need of a license) while IBM would still want to ship Linux, and SCO would get the license fees.
But more to the point is that SCO seems to be claiming that IBM coders couldn't have developed an efficient X86 scheduler - despite the fact that IBM has been writing schedulers for various platforms for decades, and the Linux scheduler is platform agnostic (and IBM contributions may well have had far more influence from running in partitions on IBM mainframe machines).
'Lighter requirements' is a pretty hard to define goal - contrary to many opinions, a Linux kernel configured to have only those functions that are needed for a specific application is pretty close to the smallest size that I've ever seen those functions implemented in. (At one time gcc did not optimize well, making even a simple embedded operating environment written in and for C much bigger than one hand-crafted in assembler - but now that embedded apps are getting more complex, most embedded systems are compiled with a flavour of gcc, so that's no longer relevant)
For a TCP/IP enabled fridge magnet, you could write an application that would parse only those network packets that it was designed to handle and ignore the rest (and build and send only those packets that it needed to know about) but unless you have some programmers who are really skilled with TCP/IP,it undoubtedly costs less to just use a well developed general purpose stack such as Linux.
The per unit cost of slightly more memory/cpu power even for millions of units is still probably less than the amortized development costs (even without time-to-market costs that could be saved with an off-the-shelf stack), especially when there's no per unit cost for the OS - After all most embedded RTOS vendors charge a per unit license fee.
There is very little in the Linux kernel that can't be stripped out of a custom build if it isn't needed - and for an embedded device, that leaves very little overhead. On the other hand, nobody really wants to have to write custom drivers for standard components such as a USB hub.
I tend to think of Linux as a toolkit that you can pick and choose from. It seems the embedded developers have a similar view, with the additional ability for applications to query to see what was chosen.
Ok,
SET
I'm just about fed up with hearing blanket statements that some flavour of Unix/Linux etc. can't do hard real time without specifying (or probably even knowing) just what needs to be run as 'hard real time'. I've implemented many small, special purpose industrial systems over the years, and most of the ones that I have had to deal with had 'hard real time' requirements in the tens of microseconds range, and I've used some flavour of *nix for implementing such systems ever since Xenix on the 286 became available.
The things that Linux can't do is to guarantee that a user-space application will be able to respond to an external stimulus in some small number of microseconds, or will be able to access slow shared resources in some small number of milliseconds.
So what? By most definitions of 'hard real time' then even reading data from a serial line is a 'hard real time' application in itself - if you don't read the character before the next character arrives (or the buffer fills for modern chips) it will be lost - this is a 'hard real time deadline' but nobody questions Linux's ability to do this. You don't need an actual application to buffer each individual character though, This is done by the kernel driver i.e. in the interrupt handler.
Even with old minicomputer real-time operating systems (specifically Digital RT11) the OS couldn't keep up to sub-millisecond deadlines, so I wrote device driver routines to do the 'hard real time' functions.
Moving to *nix systems simply kept the necessity of a device driver to handle the 'hard real time' part of the application.
Similarly, for a lot of 'fridge magnet' applications, you don't need that high a level of real time application support - just a kernel driver for the actual physical I/O applications.
With a pre-emptable kernel, and NO USER APPLICATIONS, just the device's linux appplication code for things like a UI, TCP/IP stack and similar $20 device requirements, application response times can still be guaranteed within fractions of a millsecond.
Only when you get into systems with things such as user supplied apps (i.e. causes unpredictable running conditions) or resource contention (such as needing to prioritize file access on a slow device) does the application response time become unpredictable, and for the scale of many embedded (and even non-embedded) applications this is not a problem.
Very few applications (as opposed to device drivers) need sub-millisecond response anyway. Consider that when a human is involved in the loop, anything less than about 10 milliseconds of lag is not discernable. Despite the observation in software testing (and other things) that errors predicted to occur once in a million times tend to happen 9 times out of 10 (because there is no real 'random choice' in most software), absolute timing guarantees are not often needed. But 'soft real time' capability is a necessity for any UI to be usable. I'd be unable to type this if Linux couldn't do at least that much.
On the other hand, I've had to work with some 'hard real time' systems that guarantee absolute worst case 100 millisecond response - but cannot under any circumstance respond any faster than that!
Dammit, obviously my attempt at sarchasm bombed.
But actually reading the law : IANAL, therefore my opinion isn't worth sh*t on that,
there is nothing that gives the copyright holder permission to defeat the technological measure in order to force access to the copyright holder's work when it is controlling access to other copyright holders works - and the technological measure in this case still meets the rest of the definition.
As far as I can tell the authority of the copyright owner only extends to the content of the message (the spam itself), not to the the technological measure.
Unless the spammer has copyright to all of the mail that is arriving, he is still bypassing that protection, and does NOT have the authority of the copyright owners.
It may even be arguable that the spam is bypassing the protections and modifying (by adding his spam to the incoming mail) the context of other copyrighted works.
I'd certainly consider that any spam that got past my spam filters is primarily designed or produced for the purpose of circumventing a technological measure that effectively controls access to a work protected under this title;
said protected work being the compilation of the desirable (and copyrighted) messages.
Sky and Telescope also has an article on the comet.
This article also points out the unfortunate fact that when the comet is at it's brightest, it will be directly on the opposite side of the sun, and impossible to observe from the Earth.
As a competent evil overlord, I will NOT create fearless troops. Troops that are fearless will not be afraid to try to overthrow ME.
--
Note - any henchman that thinks that this is insightful instead of funny is reading too much into it, and should be immediately sent for a session with my new zombification system.
While setting up honeypot addresses in itself seems to be a good idea, I suspect that it would be a good idea to be sure that any item to which the address is attached or displayed carries the notice you mention - by sending to that email address the spammer grants publication rights to the Great Spam Archive - so that there can be no accusation that there was no way for them to know about it before they sent the message.
:). (I wonder if the disclaimer could mandate a $100,000 item removal fee?)
For that matter, it might be worthwhile to add a rider to the notice something along the (properly translated to legalese) line of:
"Also, by sending to this address, the sender agrees to pay an archiving fee of $500 per item."
If they claim copyright, then you know who to claim the archiving fee from
It seems that various spamhaus operators are a litigious bunch. They have regularly sued blackhole lists claiming their spam to be legal, even though at least one Australian case was thrown out of court. And it seems as though for every actual threatening letter sent by an actual lawyer, it seems they send about a dozen (or more) that clearly are not.
As it happens, this particular case appears to be one of the latter. It costs them nothing to try, but it costs the recipient time in making the distinction. Typical for spam.
I don't know where the physical location of the spam archive is, but if it is located in a jurisdiction that actually has some meaningful anti-spam laws, then chances are good that the referenced 'copyright' spam is illegal - in which case claiming copyright should allow an immediate countersuit (by a real lawyer, even) since the identity of the party responsible for sending it is now firmly established.
( I can't resist joking: Nobody expected this spammish imposition.)
RFI chokes are NOT simple magnets (nor are they permanently magnetized like a magnet).
What they are is a ferrite core that makes a complete closed loop around the cable. Radio frequencies currents can't go through the middle - it blocks high frequencies. (If you want to get technical, the radio frequency current induces a magnetic field in the choke, and the change in magnetic field induces a voltage that exactly opposes the current.)
While strip magnets are made from a similar material, you simply cannot make it as effective as a proper choke.
On the other hand, the original question mentions hum - presumably AC 60Hz - and a choke will have negligible effect on a frequency that low.
No, not Itty Bitty - Instead of mo, it's less, or low - Lozilla!
:) ]
[And as a bonus, that comes out as one letter ahead, as well
If it's a lighter weight implementation of the Mo-zilla browser, wouldn't that make it Lesszilla? :)
I think you may have been the unwitting victim of a fairly common joke that occasionally was pulled on the innocent visitors when I was working in a university computer lab in the early 70s.
:)
The lab had a PDP8M that was the controller for a prototype communications network between quite dissimilar computers. Due to the data sizes involved, the program counter register would have all it's bits flickering, but the accumulator would only have 8 bits flickering (it was exclusively handling octets of data all the time) and one other register - index? - I forget now - would only have 4 bits flickering (because this prototype network only had 4 nodes, numerically 1, 2, 4 and 8, so we could see the pattern in the lights to tell which nodes were using the network).
So we used to tell visitors who didn't know better that the switch changed the word length from 4 bits to 8 bits to 12 bits, and we left it on 12 bits because it was obviously faster (the program counter changed faster than the other two as well.... and the machine was slow enough that you could see the difference.)
Sorry about that
Then they find a trace, and the speed is then measured (using the time delay in the seismic record) to get the speed of 400 Km/s - and the above figures just sanity check this as a plausible value.
It's neither proven nor even accepted that strange quarks can convert normal top and bottom quarks to strange quarks and continually grow such matter. While the strange quark is massive enough to provide sufficient energy to create many normal quarks, it is much less likely that a combination of quarks can generate a new strange quark. The expected numbers of strange, top, and bottom quarks in a strangelet are all approximately equal, so there would be an upper size limit on the mass that the strangelet itself can accumulate (until you get to the sizes and energies involved in the postulated quark stars, anyway.). As a matter of fact, it has been postulated that strangelets can actually evaporate by neutron emission, stimulated by relatively low speed collisions with air molecules. On the other hand, it could be a lump of ice with the strangelet at the center. It has also been suggested (and partly confirmed by observation of cosmic ray debris at high altitudes) that interaction cross section of a strangelet is MUCH smaller than that of a normal nucleus, let alone the size of a normal atom - such that it could actually sit between the atoms of an ice-ball without interacting with them.
These factors are a good thing, otherwise each strangelet that hit the earth would emerge MUCH heavier than it went in, and also, much slower, making it very likely to be captured by the earth (or at least the solar system) and thus would have converted us all into something
This could make for quite an explosion as that mass entered the atmosphere - my math is based on pure guesswork, but it seems that the combination of hydrogen ice, heated to a plasma in a shockwave, and the massive strangelet creates an extremely high local pressure and temperature. (Seems similar enough to the designs for mini-black-hole catalyzed fusion that it might even result in a fusion reaction - but I'll not speculate on that.)
The two entry points noted here - one was in barren antarctic land and the other in the uninhabited and infrequently traveled southern ocean - could have had a multiple megaton blast associated with them, but there would be nothing at the surface to retain evidence - no trees to be knocked down, nothing permanent to record the event, out of the scan area of most satellites, that even if there WAS an explosion, we would be unlikely to find any evidence.
Then again - I've already wondered elsewhere if this couldn't explain the Tunguska explosion.
It's pretty obvious that the article has the amount of time wrong. The suggestion of speed given by the article is that the particles might travel at about 400 Km/s, and this particular track apparently went in near a pole and came out near the equator - a rough guess (somebody else can do the actual spherical trig.) is 8500 Km of travel through the earth, and at 400 Km/s that's about 21 seconds, which is on the close order of the 27 seconds you noted from the map.
.73 of a second, then the alleged particle was travelling close to 12,000 Km/s - 4% of lightspeed - I suspect that 400 Km/s is more in tune with both the energies (not) observed, and the (escape) velocity that could be imparted by falling into the solar system from interstellar space. (At least, either way, it sounds like this one won't be coming back.)
Now if it WAS
Unfortunately, the seismography data that is not associated with earthquakes stopped being collected by the USGS (or at least, is not archived) since 1993.
:)
I suspect that funding an archive for this data would be far less expensive than the huge particle physics machines that are searching for similar matter
Not to mention - it might just be worth calculating the orbital path of the particles that were (or might be) detected, just to make sure that they aren't coming back. Given the energy they apparently release, this could even be an alternate explanation for the Tunguska explosion in Siberia. (Other than exploding meteorites that don't leave a crater, and a misfire of Tesla's Death Ray.)
Thus the normal response for open source is not RTFM, but RTFS.
(And at least, the source is available - and often has the necessary documentation embedded in it.)
I'm no expert at translating from legalese, but it sure seems that $500 is for past revenues, in 1998 - and there's a $2000 per year minimum after that, i.e. $6K for 1999, 2000, and 2001, and then another $2K minimum for 2002. And that's just to settle PAST broadcasts. So there's a minimum outlay of about $8500 for ANY webcaster that's been around for those years.
Even if a webcaster is non-profit, with no income, they want 5% of expenses - still subject to the minimums.
Oh, and you're a small webcaster until you make more than a $1.25 Million?
As aside, most of the 'Rocket science' complexity is actually done away with in this design. Simply having a fixed mount for the engine cuts out a LOT of complexity. And reducing the complexity will definitely reduce the cost.
I did find, however, reference to porous rock structures saturated with methane hydrate, however, that keep the methane hydrate at just that slightly higher pressure needed, and that WILL burn as the methane hydrate within breaks down. There was also reference to such rocks indicating deeper oil and reserves.Yeah, a story where people claim 'large reserves' and confuses '850 metres below the sea floor' with '850 metres below the surface', combined with the local temperatures, and the existence of porous rocks with methane hydrate in them. It's quite possible that the actual subject of the story has very little to do with large deposits of pure methane hydrate right on the sea floor. (Such relatively pure deposits exist - I'm just not sure of the CBC story about this one location.)
Just because the CBC has reported something doesn't mean that they got the story right. I can easily see a reporter - or anyone with second hand information and a little knowledge of methane hydrates - confusing the two possiblities.
It could be rocks saturated with methane, similar to those found under the North Sea - but if that's the case, the deposit itself is practically worthless (how much rock would have to be brought to the surface and crushed/heated/whatever in order to release the methane?)
More likely, these are just (again as in the North Sea) just an indicator that there are deeper reserves of oil and/or gas below the seafloor, and little to do with methane hydrates.
For that matter, althought he article says 'in about 850 metres of water', the text on the picture shows '850 metres below the ocean floor' - NOT the same thing.
This might even have the effect of bringing deep nutrients to the surface and improving local fishing (sort of like the natural upwellings that support huge fish population in other areas).
Hmm. How soluble IS methane in low-pressure water? I seem to recall that some single-cell critters can eat methane - would they work as the basis of a food chain, perhaps?. It could be the basis for some intensive fish-farms, too.
On the other hand, though, I can't find any information on how pure the methane extracted might be - if it's got high sulphur content or other similar problems, it might not be quite as good a fuel as might have been hoped for - and could be even worse disolved in seawater.
If the firmware were rewritten by any means, though, the way that the mouse interacts with the driver wouldn't have to change, either - it would be sufficient to provide an extra 'button' signal (button 6 maybe - definitely not 'middle') that corresponds to whether the center of the sensor area last became lighter or darker.
The addition of such a 'button' singal would be sufficient for application software to determine the presence and content of any barcode - assuming that the user was able to move the correct portion of the mouse over a valid portion of the barcode.
Frankly, though, the easiest device to turn into a barcode scanner would be a simple top-of-the-monitor type webcam