Bluetooth is heavily targeted for telephony.
on
USB Going Wireless
·
· Score: 5, Informative
I don't see it that way. Bluetooth is a great technology. It's slow speed do limit it's applications, but for you mouse and your keyboard and syncing up your cell phone and such, it works great and there is no reason to replace it. It is also low power, isn't it?
Bluetooth is heavily targeted toward telephony applications.
One thing that "IP guys" are constantly missing the importance of is the need to deal with timing in streaming applications. (The telephone people missed it too, when they initially went digital, and spent decades fixing it up after the fact. Their latest generation - SONET - is orgznized around clocking. "Synchronous" is even the first word in the acronym.)
Basic idea is that, when you're sending a real-time stream at a constant sample rate, if you have a common timing reference at the transmitter and receiver things are a LOT simpler than if you have to infer the timing of the transmitter at the receiver. Doesn't matter if you propagate it with the signal or both ends get it from a common source by some complicated path - just get them clocked alike to make the endpoints' jobs enormously easier.
Voice signals, for instance, play out fine if the clocks at the two ends are synchronized, but have annoying clicks if not. These clicks can be cleaned up by adding heavy processing - which trashes FAX and high-speed modem signals. But that means adding a DSP (or equivalent computation) for uncompressed signals, or extra DSP work if you already having one doing compression. This takes power, at a premium in portable applications, and extra (or faster) silicon, which can raise costs. And even then the result is usually not as good as if the clocks were synchronized in the first place.
Phone companies synchronize nearly everything in their networks to a common clock, especially the 8,000/second sample rate of the A-to-D conversion of the voice signals, and distribute digitized voice (when uncompressed) as 64 kbit signals (8,000 8-bit samples per second.)
Bluetooth is organized around this. Time is broken up into 16,000 slots per second, with the master and the slaves taking turns - 8,000/second each. (What a conincidence that it's the voice sampling rate, eh?) The master sets the timing. The number of active slaves is limited, but a slave can extend the net to more active devices by becoming the master of a subnet. This makes little sense for net organization, but perfect sense if the slave is propagating timing from the master. Channel allocation within the net includes a fat general-purpose data channel plus three constant-rate bidirectional 64Kbit channels. (I.e. three phone calls.) A slave can participate in two separate nets - and can terminate all three 64K channels if in one net, or two of 'em if one is from each.
What this means is bluetooth is perfect for things like wireless headsets for cellphones. The cellphone provides a clock to the headset to set its sample rate, and the headset sends and plays out uncompressed audio. So the headset requires no DSP, little silicon, and little power. (The Bluetooth modulation scheme also makes for a simple, low-power, DSP-free radio.) The cellphone already has a DSP for compressing audio on its way to/from the net. It can in principle propagate network clocking to the handset, making things better end-to-end. Or it can just use its local clocking to make headset/DSP communication easier.
So Bluetooth makes design of cellphone audio peripherals nice. Cheaper, lower power, longer battery life, lighter weight, compared to any of the other schemes which don't propagate a phone-network or piconet-local timebase accessable beyond the network stack and/or require heavy DSP processing to work at all. Thus it's unlikely cellphones will be moving away from it any time soon - and when they do they'll probably move to something else that also propagates clocking. Since bluetooth can also handle a moderately-fast data link for WAN traffic, you get wireless internet connection throu
If you put it deep enough in the fluid, the bubbles will condense on the way up.
However the shockwaves from their formation and collapse (cavitation) could cause physical damage to the chip packaging, especially where conductors penetrate it. If the chip package isn't designed for it, total immersion is proably out. Back to liquid-cooled clampons. (In which case, why not use water, which has extremely high specific and vaporization heats?)
If the heat of vaporization is anything reasonable, this should work quite well to remove heat from your chip--the fluid changing to a gas absorbs a bunch of heat,
But the heat of vaporization is extremely low compared to water - by a factor of 25! (That's why it can be "stored as a liquid and used as a gas" - the small amount of heat in the air causes a spary to immediately evaporate).
Specific heat wasn't stated - but with such a low heat of vaporization it is also probably low and/or doesn't matter. You're going to have to circulate this stuff REALLY FAST to get usable cooling.
Note that its use as fire suppression is not relevant to its use as cooling. Though this stuff DOES suppress fires by cooling (unlike halon, which interferes with the chemical reactions), fire suppression is a one-pass rather than multi-pass function. So the cooling can be accomplished by breaking up the molecule - using the heat of formation, in addition ot the the specific or vaproization heats, to cool the fuel. I doubt that you want to be continuously consuming your coolant and disposing of the resulting fluorinated alkyl radicals in your home system.
Also, I'm concerned about the toxicity.
This is being sold as a fire suppressant. Fires, and their combustion products, are SO toxic that a suppression system chemical can be quite hellish and still be a drastic improvement. But long-term exposure as an alternative to non-exposure is a far different can of worms.
One document touts that the LD50 (concentration that kills 50% of those exposed) and cardiac sensitization NOAEL (no observable effects level) - both ACCUTE (immediate) poisoning measures - are both "over 10% v/v". But another document, touting its rapid vaporization, point out that the equilibrium vapor pressur in air is four times that: 40% (nearly half the air replaced by vapor). And given how easily this stuff vaporizes, it can approach that damned quickly. So dumping warm coolant might quickly displace nearly half the air with this stuff's vapor and put you in jepoardy - of suffocation if nothing else. Not a problem if it's putting out a fire - BIG problem if it's not.
With that high vapor pressure and low heat of vaporization, exposure would tend to be very high during handling or in the presense of even a tiny leak. So if there are even small long-term toxic effects you'd want to avoid having this where it could result in repeated and prolonged contact.
The blindspot you're having is that people want free software to make inroads into new markets, but are unwilling to consider the things that make that possible.
I think you're missing something I didn't explicitly say. (Hard to fault that. B-) ) So I'll say it:
Yes, there ARE people who want free software to make inroads into new markets. Some of them are deveopers of free software and some are not.
When the person is a developer of free software, and he wants it badly enough that achieving it motivates him even more than the egoboo of putting out a well-functioning (but hard to use) project, that will motivate him adequately. Then he'll be motivated to put in the extra effort to make his tool easier to use, or recruit some other talent to get it done, and chase a still bigger subjective reward. There are a few of these. Some of them are already putting out easy-to-use projects. Others are likely to be willing to accept constructive criticism, or help, in order to find out what needs fixing.
But when the person is NOT a developer on a project, my previous posting stands verbatim.
Put up or shut up. Contribute to a project that needs usability improvements, join or start a project to apply a usability solution across multiple projects and/or create a framework, or contribute documentation. Or at least bug fixes or bug reports.
There's lots of work to be done. Flaming the existing developers won't help. Doing the work will.
If you don't like it, extend it, fix it, or hire someone to do so. Don't dump your personal application requirements on community members who are just trying to share what they have.
So what you're really saying is "hey, you didn't have to pay for it, so just sit there and shut up about how bad it is. We don't care about your problems with it and we're not going to fix it. If you think you know so much, why don't you go fix it?"
Why, yes. That's exactly what they're saying.
And why not?
People ARE getting their very useful stuff for free.
The authors wrote it to handle the problems THEY care about.
It took a lot of work to get it that far. Making it easy to use and fitting it into a common interface style with a bunch of similar problems is a LOT of extra work. Satisfying every critic takes still more - and is often impossible.
If the problem YOU care about is ease-of-use, why DON'T you do something about it, rather than bitching? Source is there. Have at it!
Put in all that extra work, do a GOOD job on it, and the original author might just adopt it into the future mainline and give you major contributor credit. If he doesn't, publish your patches, or write a wrapper. Or FORK the bastard and port his future changes into your fork as he releases 'em. (Either that will be easy, or you didn't make your changes well, which might explain why he didn't merge your stuff.) If your version is enough easier to use than the original, yours will be the one that's widely adopted.
A little constructive criticism may be handy if the authors' designs are awkward to use but easily fixed. But when fixing them would take lots of work, constant whining without contributing labor is just a pain in the butt. And it's more likely to make the author drop the project than spend still more effort changing it to conform to YOUR preferences.
When somebody says "If you think you know so much, why don't you go fix it?" HE'S JUST INVITED YOU TO JOIN THE PROJECT!
Put up or shut up!
And people wonder why average users consider OSS proponents to be arrogant and egocentric?
What do you expect? These are people with exceptional skills who are working, not for free, but for ego-strokes. Of COURSE you get arrogant egocentrics. They're in it for themselves, to make software THEY like. If they make an exceptionally good tool that achieves wide adoption on its merits they've got a lot to be arrogant about.
Get used to it.
If you want it done YOUR way you have to PAY for it - in coin, in work, in resource contributions, or in encouragement. TANSTAAFL.
And if you're going to live off other people's charity, biting the hand that feeds you just makes you hungrier.
And 400 bucks for the primary unit, that realistically isn't that bad, especially if you have a monster of a computer system that has over 120 gigs of hdd space that needs backed up.
Yes, it is pretty bad. You can buy an external 250 GiB drive for $70 less than that with similar data transfer rates.
Or buy an INternal drive for still less, and a docking station that lets you install 3" hard drives in drawers and plug 'em into a 5" bay.
I can get a docking station and one drawer for (whatever modifier is current) ISA bus drives at Fry's for under $20, extra drive drawers for under $10 last time I looked. You absolutely CREAM the price of their base unit, and for $200 you can get plugins for far more than the 140M of their four-pack of 35s. And they don't come in little chunks that make you change media several times to do a backup.
And you're not limited to one manufacturer. (Even if the docking station flakes out and you can't find a replacement OR an equivalent system to move the drive to, you can always mount the bare disk back inside your machine or run a cable to it as an emergency measure.)
I'm currently engaged in putting them in all of my machines - not just for backup, but I'm making the primary drive removable, too. Then I can pull it out when upgrading or migrating, plug it into another slot as a secondary once the new system is built, and not have to sweat whether a runaway installer might trash the data on the old disk. Then I can archive it once I've ported what I need to the new system.
I know that I will never buy a car with RFID tracking capabilities built into it!
Your state will just put it in your license plate. Watch for it.
After all, they already hang a number on your car and require it to be visible - to eyes and to OCR cameras. Why not require it to be readable by radio, and save themselves some cost and flakeyness by replacing cameras with transcievers?
Look at how some people find picking up new [non-computer] languages really easy, and other people of similar apparent intelligence seem to have a complete inability do this.
I took a "Psych of Language Acquisition" course in college, back in the '60s - while trying to complete a language distribution requirement, hoping it would give me pointers. Instead it hexed me.
The theory at the time was that there were certain "critical periods" in brain development, for different aspects of language acquisition (phonemes, grammar, etc.), before which acquisition of that aspect was easy, after which it was darned near impossible. Having transferred from engineering (which didn't require language) to computer science (which in those days was under "math" in "Liberal Sciences and Arts", and thus DID require a language), I was starting language acquisition late - and was thus just past the last of the "critical periods" of the theory.
I had that class the hour immediately before the German class. So (regardless of the accuracy of the theory) I had to go straight from the class where I had to BELIEVE that theory (so I could reason from it to respond quickly to problem questions) to the one where I had to do what it said was impossible. Needless to say I didn't do well in German that term.
Later I found out that some big-name anthropoligists said that the theory was bunk. Later the theory was revised to state that if you learned the relevant aspect of a SECOND language before the critical period you were able to learn that aspect of more languages afterward. And the underlying mechanism of one of the hypothetical critical periods - phoneme acquisition - is now beleived to involve the death of neurons that are not used by the phonemes of the language learned. (So to learn another after the critical period you have to grow new neurons or retarget those you are using for other purposes, rather than simply preserve existing neurons that do the right job. Those who learn a second language early would thus preserve more of the nerves and their functions - including perhaps some responsible for keeping languages separate.)
So by this new model, people who learn a second language early and/or people who have exceptional nerve growth abilities would be able to learn languages later in life.
That would correlate to some extent with my experience: As an young child I "talked to cats" - mimicing their body language and agonistic noises in context. Learning German I discovered that I could easily make the labial fricative and uvular trill - which are not in English but which I had used for "hiss" and "purr" in my childhood experiments - but had the same trouble with the labial trill as other native English speakers.
So it would be interesting to know:
- How old you were on your bike ride.
- Whether you learned one or more than one language as a child.
| THE SUDDEN FLASH OF INSIGHT OCCURS WHEN solvers engage distinct | neural and cognitive processes that allow them to see connections | that previously eluded them.
maybe its the other way around -- perhaps the distinct neural processes occur when one has the flash of insight.
That's my take, too. My impression is that the processing takes place for some time (and the mechanism is not wired for introspection of its operation, so you're largely unaware of it), producing one type of activity. Then, if a solution is recognized, there's a burst of another type of activity as the recognition is collected, checked, finalized, and/or propagated to other parts of the brain.
This seems to square with the MRI showing increased activity once the problem is given, but the EEG showing a characteristic burst of high-frequency noise just before the "AHA" is reported. Perhaps it's fair to interpret the MRI as seeing the first activity, and the EEG capturing the second.
A subjective and anaecdotal item: I get the impression that the (hypothetically pattern-matching) mechanism can call on other parts of the brain - more logical and more susceptable to introspection - at intermediate steps of the problem solving. For instance, about halfway to the solution of the "pine, crab, sauce" puzzle I remember thinking that they all looked food related and that the search should focus on food-related words. This step didn't seem to generate a full "aha", but it didn't follow from logic either. So perhaps a preliminary report of a potential weak correlation was reported out for logical checking and a "looks good, pursue it further" signal went back.
That might imply that the "aha" burst involves a rapid set of confirmations of fit on different parts of the proposed solution.
I've long thought of the thinking process as involving a world-model-building mechanism that includs pattern matcher(s) that hunt for connections and correlations, often finding false-positives, plus (hypothetically more sequential) checking process(es) that test the new correlations against the model and discard them as false or rearrange the model if they are accepted (possibly discarding previously accepted matches) - with pattern-matching assist to identify where checking should occur. Perhaps these results could put some rivets into such a model.
How about... Using Wine to emulate Windows to emulate Linux...
Probably wouldn't work. I doubt Wine (not)emulates that part of Windows.
But you should be able to do it the other way around: Run Windows apps in Wine in Linux in CoLinux in Windows.
Wouldn't be totally silly either: You could more ealisy compare the apps behavior under Wine and under Windows. (Though if it was sluggish or flakey on the Wine/Linux/CoLinux/Windows stack you'd have to confirm with Wine on native Linux to be sure it wasn't an artifact of running Linux under Windows.)
You mean the already available binaries bundled with Cygwin? Or coming up with a Win 32 copy of Mozilla? Or GCC? Or even the Gimp? Or do you mean Open GL apps? Or Vim? Emacs? Etc etc etc.
Nope.
Any existing linux binary. Any new linux binary.
Like that internal application that your company wrote whose source got lost.
Or the complicated one you got debugged and deployed on your department's native Linux platforms and you want to be sure runs EXACTLY THE SAME WAY on the boss' Windows box.
Here's a section of Canadian law pertaining to this.
Relevant portion:
[...] has in his possession any instrument suitable for the purpose of breaking into any place, motor vehicle, vault or safe under circumstances that give rise to a reasonable inference that the instrument has been used or is or was intended to be used for any such purpose, [...]
So even in Canada it's legal to have lock picks, crowbars, jimmies, paperclips, stethoscopes, etc. But it's a crime to be carrying them "under circumstances that give rise to a reasonable inference" that you intended to use 'em for no good, without documentation on you to the contrary.
Basically Canada has made explicit the assumption of guilt under such cricumstances. Down south here we have this Constitution that says our white-hats aren't supposed to do that. So they have to be a bit more subtle when they want to create the presumption of guilt. (Of course some of 'em do it anyhow.)
Basic point in either case is that you risk getting busted if you tote 'em around in places where you might be mistaken for a crook, unless you use 'em in your legal line of work and have papers on you to prove it. Even without Canada's presumption of guilt, having 'em in such circumstances is an extra indicator of criminal intent.
So the onus is on the individual to prove that they have the tools for a legitimate reason. That's pretty difficult to do unless you are a locksmith.
Yep. Look bad to a Canadian cop and you find yourself guilty until proven innocent - and you'd better have proof on you.
And even down here it's a good move to assume that you'd be treated to free room and board if you dress shabbily and hang out near locked buildings full of valuables that aren't yours with lockpicks in you pocket or a crowbar in your backpack.
But keep 'em in your safe at home and you're legal. It just becomes an extra kicker if they bust you for B&E, get a warrant, and search your place.
Ohboy! Now you can have pretty pictures to ...
on
UML Fever
·
· Score: 2, Informative
I'd like to see a true OOPs language like Smalltalk (OOPS are strong on prototyping) and UML (Strong on graphical modeling) combined with that tool mentioned awhile back that converts sketches to a refined diagram (Tablet PC's or Electronic Whiteboard). Throw in ad-hoc annotation capability and we are almost there.
Oh, boy. Now we can engage in rabid prototyping and have pretty pictures on the wall, too.
Bring up Smalltalk - or other rapid prototyping systems - and you demonstrate that the methodologies are leading you into the design-religion morass.
Rapid prototyping has been responsible for a plethora of project failures. This is because it consists of attempting to code without a design. That works if one person can keep the whole thing in his head, and breaks when the problem is large enough to need partitioning.
Rule of thumb: If rapid prototyping doesn't complete in 30 days, the project is to big for it. You must fall back on other design methodologies to succeed. Or you can continue for as much as a few years but you will eventually fail.
What you're talking about appears to be hanging automated tools on the rapid prototyping system to automatically infer the design document from the code. (Essentially, you're hanging the skin of a formal design methodology onto rapid prototyping in the hope of patching some of the latter's problems.) This is a cart-before-the-horse approach. But it also backs into the "self-documenting code" and "provable correctness" fallacies.
(It also reminds me - in style if not in substance - of a certain wild-eyed Smalltalk visionary's claim that software testing methodologies would have to improve until they could test his design in less than 30 minutes - because that's how often he changed it. B-) )
The key to robust code is to design it TWICE: Once as a human-readable spec, again as code. One must NEVER be automatically generated from the other - because debugging doesn't find bugs, only disagreements between specified and actual behavior. A particular implimentation of "cat" is VERY buggy if what you wanted was "ls". This is why correctness-proof tools aren't a panacea (and are misnamed): They work from a spec of what is correct, and writing a formal spec is ALSO a programming problem, subject to error.
It's OK for both the doc and the code to be in formal languages. It's OK for there to be a set of tools to perform part of the comparison between them automatically. But if you generate one from the other automatically, the only thing you can test is your generation tools. If it doesn't do what was intended that won't show, because the spec and the code will both prescribe the same "broken" behavior. And it's OK for a human to work from a spec toward code - because he'll be giving critical thought to the spec as he codes, and thus tends to discover spec errors.
But it's important for the two languages to be as different as practical, to put the designer and the programmer (especially if they're the same person) into different mind-sets when writing each. The more different they are, the more likely it is that problems will be discovered during the generation of one or the other. (This is why correctness-proof tools are useful despite being misnamed.)
In a real-world project the code and the design co-evolve to a significant extent. When you find a bug it's usually in the code (because the design went ahead of the code and had much standalone debugging). So you fix the code. But sometimes writing the code exposes a bug in the design. Then you fix the design. When you're done the code and design agree - and they're both near-perfect because the final versions of both withstood the entire trial-by-fire and many-eye inspection.
Your analogy of software security to (presumably) physical world "invasion" tools (e.g., lock picks, etc.) causes me to make a prediction. The prediction is that, like lock picks, the use and possession of software security tools may in the future be licensed and regulated.
Last I heard, the possession of lockpicks was generally NOT regulated - no matter what the locksmithing industry would like you to believe.
Like crowbars, the crime is possession with intent to use illegally. (Unlike crowbars, it's a lot easier to show intent to use a lock pick as a burglary tool.)
However IANAL and have not studied this issue closely. (Also it's state level issue, so both the laws and precedents vary.)
So reverse engineering is not a problem in this case. In fact, it's not unlikely that AMD simply handed them the documentation.
Reverse engineering is NEVER a problem. The very concept that it MIGHT be is recent - and driven by propaganda from the software industry.
Historically, industries have reverse engineered nearly everything: Cars, looms, what have you. (Auto compaines, for instance, have entire DEPARTMENTS to disassemble and reverse-engineer their competitors' products.)
You can patent an idea - which gives you a lock for a number of years on using it in a commercial product or process. But that immediately exposes it, and releases it to the public domain once the time is up.
Alternatively you can keep it secret, and hope the secret stays secret and nobody reinvents or reverse-engineers it. But once the cat's out of the bag you have no protection whatsoever. If you show the secret to an employee or business partner, and they leak it or use it beyond the limits of the contract, you can sue THEM and enjoin them against further disclosure. But if the "secret" has spread beyond catching, or if it is rediscovered/reinvented or discovered by examining a product you sold, tough luck!
Software companies have tried to stretch trade secret via ELUAs claiming you're a "business partner" rather than a purchaser of a product, and thus contractually forbidden to do reverse-engineering. And they've tried to stretch copyright similarly, claiming you have to copy it to use it to reverse engineer and that's forbidden by your license (first-sale doctrine be damned). But (except for the DMCA, which has yet to be adequately tested) there's essentially no foundation in law for these claims.
Or at least that's how I (who ANAL) read it.
Big airbags - bubble wrap - foam - cones.
on
Personalized Moon Crash
·
· Score: 5, Interesting
I think we can safely guarantee the condition of just about any cargo which hits the moon at that speed.
Implying that it will be destroyed, right?
Not necessarily.
This is just an extreme case of the "egg drop" problem used by the UofMich ingineering school ion their packaging class one year (and no doubt other engineering schools from time to time).
Problem: Package a raw egg with less than (x) grams of packing material so that it can be dropped from the roof of the four-floor engineering building to the concrete below and arrive intact.
A number of solutions were tried. Some I remember hearing about:
- Suspended inside a ball by rubber bands.
- bubble wrap variants
- foam peanut variants
- Stuffed into the top of a stack of styrofoam cups with kleenex, fins added to last cup to insure bottom cup arrives end-on. (Energy absorbed by friction of cup stack cracking and collapsing).
(That last one was a winner and led directly to the nested-sheetmetal protectors you sometimes see on freeways in front of overpass support piers.)
Then we have NASA's recent "airbag" landing on Mars.
4K MPH is a bit extreme. But you've got a LOT of space to, for instance, blow up a LARGE airbag/bubblewrap analog, and plenty of time to do it.
Encapsulated electronics, and even moving parts if packed correctly, can handle thousands of Gs easily. (Think about MOOG's final test for his synthesizer components: Three feet to a cement floor, must stll be fully operational and still correctly tuned afterward.) 4000 MPH = 5867 fps. Bullets are routinely accellerated to that velocity in a few feet without distortion from the g forces involved (though that is a bit extreme), and bullets with moving parts (such as spin-armed explosive rounds) to maybe a couple thousand FPS ditto.
So figure inflating maybe a 50 foot radius cluster of 'way thin kevlar balloons or bubble-wrap with aerojell just before impact, and taking maybe 20kg at the peak of decelleration, and it should be survivable.
But DeCSS got leaked when it was still a stand-alone module developed within a windows application. This weakened the argument that the purpose was to generate a Linux player. (It was, and this was a convenient intermediate step, but it still weakened the argument.)
PlayFair is a complete application which refuses to operate unless you have the appropriate license for playing the content, and only performs conversions that all aid recognized fair use. Since it's open-source its guts COULD be ripped up and rehacked into a pirate tool. But as distributed the functionality is strictly within the bounds protected both by copyright law AND the DMCA.
Apple has not come close to proving that a law has been broken [...]
I can only conclude that OSDN are either lazy, scared of Apple, or have interests in Apple.
I conclude something else.
SourceForge is a major resource for FOSS, serving as the project host and canonical version maintainence site for a large number of projects.
Fighting for this particular one, winning, and establishing a precedent, might be useful. But it would be DAMED expensive, and DAMNED risky. A loss - or even an expensive win - would take out the resource.
And fighting it is not NECESSARY. Because the project is already multiply mirrored (no doubt by a large number of people who realized this would be coming as soon as the project was announced) and officially rehosted at one of those mirrors, beyond the direct reach of US law.
The secret to winning a war is to fight it on your own terms. RIAA and its cronies are like a small herd of elephants. FOSS is more like a prarie-dog colony - or perhaps several hives of army ants. One side has great strength, the other great numbers and diversity but little strength in any one place. How should the diverse side fight this battle? One-on-one fight? Or "whack-a-mole"?
"The Colonists win the toss. The British have to wear red uniforms and stand in rows. The Colonists get to wear brown and green and shoot from behind trees and rocks."
When you buy music from Apple you are buying it under a specific contract and by buying it you are accepting the terms of that contract which limits the use of the music. Don't like the terms, don't get it from Apple.
Flip this around and imagine that I decide to circumvent the GPL by taking a piece of GPL software and using its source in piece of closed source commercial software. Wouldn't like that now, would you?
Neither Apple's contract nor the GPL trumps Fair Use. Copyright doesn't prevent doing what you want with your own copy within certain limits. Copyright doesn't prevent proprietary software vendors from incorporating parts of GPLed software in proprietary products, again withing certain limits.
In the case of music, the limits allow making format change copies for personal use and giving away or selling the original if you don't keep a copy - but prohibit giving away or selling clones (or the original but keeping a clone), giving public performances, or doing a "cover" version in violation of the license terms.
In the case of GPLed software the limits allow small snippets of code to be incorporated or the functionality to be replicated with newly-written code, but prohibit copying of substantial sections, wholesale distribution, or straightforward translation, in violation of the license terms.
DMCA is a whole new can of worms, creating a catch-22 to block the exercise of fair use rights. This will eventually get shaken out in the courts, one way or another. But don't hold your breath waiting for that. It might take decades, or generations.
Speeder not the only one punished......but also everyone behind him/her.
It's San Francisco. Individuals are not responsible for their actions. Guilt only applies to groups. They're all driving cars, so they're all equally guilty. And they all need to get over their love affairs with cars and use public transit. (Even if it doesn't go where then need to go, or takes several hours to replace a 10-minute car trip and costs far more, or stops running after 6 PM and doesn't restart until Monday.)
5MW is good for 10,000 homes, so a house in Scotland only uses 500 watts of electricity?
Rule of thumb for the US is 1 KW/home "fleet average B-) ". A LOT of that is either air conditioning or (in the few remaining ones from the "it's going to be too cheap to meter" era) electric heating and/or electric water heating, in the houses so equipped.
Resistance heating is HORRIBLY expensive in terms of power consumption. (More than a factor of three inefficiency compared to burning the same fuel to apply heat directly.) Air conditioning comes in two forms - heat pumping (also very energy intensive) and evaporative (only usable in arid areas, and an allergy and toxin problem, so much less common).
Scotland has a very mild climate compared to the US. It sits at the end of the gulf stream, which provides heating that nicely compensates for its latitude and moderates its climate dramatically. (For an extreme of this effect look at "Summer Isle" - just off the coast on the gulf-steam side and growing palm trees.) The US is spread out over a continent, with considerable variation in latitude and altitude - and thus temperature. The mountains on the upwind side also dump the moisture out of the prevailing winds and their heat of vaporization into the atmosphere, creating the western and soutwestern deserts.
No, I wouldn't be at all surprised if the US averages twice the domestic electric consumption of Scotland.
This is all part of an alien conspiracy to bring the moon crashing down on us! Awaken to the truth before it's too late!
Actually, tidal friction slows the rotation of the earth and raises the orbit of the moon. Extracting tidal power will increase the friction and thus the rate at which this happens.
(Of course if there WAS a chance of bringing down the moon that would make for QUITE the "environmental impact".)
This is mostly about consolidating control of not only the data center but the desktop within corporations.
IMHO this, like the investment in Apple, is about Microsoft trying to head off future legal trouble.
Sun and Apple were essentially the only direct commercial competitors to Microsoft. Right now Sun is dying - and Microsoft has a track record of screwing them. If Sun goes under Microsoft gets bit big-time in the NEXT anti-trust suit.
So just as they did when Apple was about to fold, MS gives 'em enough money to keep 'em afloat.
People have been saying their payments to Sun are peanuts. But they're a LOT of peanuts: MS just gave Sun one out of every 25 peanuts they have. There are only two reasons for them to do that:
- To make even more money later as a result.
- To avoid losing even more money later as a result.
There's no WAY this is going to make them more a couple of billion any time soon. So it's got to be avoiding the loss of more.
One moment they are advocating how big linux and OSS movement is, the next moment backhand deal with MSFT.
Sun has a long history of vacilating on openness.
They did it with SPARC. They did it with their OS. And so on.
I jumped to Linux from Sun primarily because I wanted to do some HW/SW hacking. Linux (and the BSDs) are open, as is the hardware they run on. The sofware is certain to stay that way, and the hardware likely either will or will be hacked. But it's just too much of a pain trying to get HW and SW info on Sun/Solaris platforms.
Slashdot Mirror
I don't see it that way. Bluetooth is a great technology. It's slow speed do limit it's applications, but for you mouse and your keyboard and syncing up your cell phone and such, it works great and there is no reason to replace it. It is also low power, isn't it?
Bluetooth is heavily targeted toward telephony applications.
One thing that "IP guys" are constantly missing the importance of is the need to deal with timing in streaming applications. (The telephone people missed it too, when they initially went digital, and spent decades fixing it up after the fact. Their latest generation - SONET - is orgznized around clocking. "Synchronous" is even the first word in the acronym.)
Basic idea is that, when you're sending a real-time stream at a constant sample rate, if you have a common timing reference at the transmitter and receiver things are a LOT simpler than if you have to infer the timing of the transmitter at the receiver. Doesn't matter if you propagate it with the signal or both ends get it from a common source by some complicated path - just get them clocked alike to make the endpoints' jobs enormously easier.
Voice signals, for instance, play out fine if the clocks at the two ends are synchronized, but have annoying clicks if not. These clicks can be cleaned up by adding heavy processing - which trashes FAX and high-speed modem signals. But that means adding a DSP (or equivalent computation) for uncompressed signals, or extra DSP work if you already having one doing compression. This takes power, at a premium in portable applications, and extra (or faster) silicon, which can raise costs. And even then the result is usually not as good as if the clocks were synchronized in the first place.
Phone companies synchronize nearly everything in their networks to a common clock, especially the 8,000/second sample rate of the A-to-D conversion of the voice signals, and distribute digitized voice (when uncompressed) as 64 kbit signals (8,000 8-bit samples per second.)
Bluetooth is organized around this. Time is broken up into 16,000 slots per second, with the master and the slaves taking turns - 8,000/second each. (What a conincidence that it's the voice sampling rate, eh?) The master sets the timing. The number of active slaves is limited, but a slave can extend the net to more active devices by becoming the master of a subnet. This makes little sense for net organization, but perfect sense if the slave is propagating timing from the master. Channel allocation within the net includes a fat general-purpose data channel plus three constant-rate bidirectional 64Kbit channels. (I.e. three phone calls.) A slave can participate in two separate nets - and can terminate all three 64K channels if in one net, or two of 'em if one is from each.
What this means is bluetooth is perfect for things like wireless headsets for cellphones. The cellphone provides a clock to the headset to set its sample rate, and the headset sends and plays out uncompressed audio. So the headset requires no DSP, little silicon, and little power. (The Bluetooth modulation scheme also makes for a simple, low-power, DSP-free radio.) The cellphone already has a DSP for compressing audio on its way to/from the net. It can in principle propagate network clocking to the handset, making things better end-to-end. Or it can just use its local clocking to make headset/DSP communication easier.
So Bluetooth makes design of cellphone audio peripherals nice. Cheaper, lower power, longer battery life, lighter weight, compared to any of the other schemes which don't propagate a phone-network or piconet-local timebase accessable beyond the network stack and/or require heavy DSP processing to work at all. Thus it's unlikely cellphones will be moving away from it any time soon - and when they do they'll probably move to something else that also propagates clocking. Since bluetooth can also handle a moderately-fast data link for WAN traffic, you get wireless internet connection throu
If you put it deep enough in the fluid, the bubbles will condense on the way up.
However the shockwaves from their formation and collapse (cavitation) could cause physical damage to the chip packaging, especially where conductors penetrate it. If the chip package isn't designed for it, total immersion is proably out. Back to liquid-cooled clampons. (In which case, why not use water, which has extremely high specific and vaporization heats?)
If the heat of vaporization is anything reasonable, this should work quite well to remove heat from your chip--the fluid changing to a gas absorbs a bunch of heat,
But the heat of vaporization is extremely low compared to water - by a factor of 25! (That's why it can be "stored as a liquid and used as a gas" - the small amount of heat in the air causes a spary to immediately evaporate).
Specific heat wasn't stated - but with such a low heat of vaporization it is also probably low and/or doesn't matter. You're going to have to circulate this stuff REALLY FAST to get usable cooling.
Note that its use as fire suppression is not relevant to its use as cooling. Though this stuff DOES suppress fires by cooling (unlike halon, which interferes with the chemical reactions), fire suppression is a one-pass rather than multi-pass function. So the cooling can be accomplished by breaking up the molecule - using the heat of formation, in addition ot the the specific or vaproization heats, to cool the fuel. I doubt that you want to be continuously consuming your coolant and disposing of the resulting fluorinated alkyl radicals in your home system.
Also, I'm concerned about the toxicity.
This is being sold as a fire suppressant. Fires, and their combustion products, are SO toxic that a suppression system chemical can be quite hellish and still be a drastic improvement. But long-term exposure as an alternative to non-exposure is a far different can of worms.
One document touts that the LD50 (concentration that kills 50% of those exposed) and cardiac sensitization NOAEL (no observable effects level) - both ACCUTE (immediate) poisoning measures - are both "over 10% v/v". But another document, touting its rapid vaporization, point out that the equilibrium vapor pressur in air is four times that: 40% (nearly half the air replaced by vapor). And given how easily this stuff vaporizes, it can approach that damned quickly. So dumping warm coolant might quickly displace nearly half the air with this stuff's vapor and put you in jepoardy - of suffocation if nothing else. Not a problem if it's putting out a fire - BIG problem if it's not.
With that high vapor pressure and low heat of vaporization, exposure would tend to be very high during handling or in the presense of even a tiny leak. So if there are even small long-term toxic effects you'd want to avoid having this where it could result in repeated and prolonged contact.
McDonald's lost the right to use their famous golden arches in South Africa because another local South African company beat them to it.
Ditto in Canada - but I hear they bought 'em out.
(Total clone of system, mark, etc. - except add a little red maple leaf over the point where the two arches cross.)
The blindspot you're having is that people want free software to make inroads into new markets, but are unwilling to consider the things that make that possible.
I think you're missing something I didn't explicitly say. (Hard to fault that. B-) ) So I'll say it:
Yes, there ARE people who want free software to make inroads into new markets. Some of them are deveopers of free software and some are not.
When the person is a developer of free software, and he wants it badly enough that achieving it motivates him even more than the egoboo of putting out a well-functioning (but hard to use) project, that will motivate him adequately. Then he'll be motivated to put in the extra effort to make his tool easier to use, or recruit some other talent to get it done, and chase a still bigger subjective reward. There are a few of these. Some of them are already putting out easy-to-use projects. Others are likely to be willing to accept constructive criticism, or help, in order to find out what needs fixing.
But when the person is NOT a developer on a project, my previous posting stands verbatim.
Put up or shut up. Contribute to a project that needs usability improvements, join or start a project to apply a usability solution across multiple projects and/or create a framework, or contribute documentation. Or at least bug fixes or bug reports.
There's lots of work to be done. Flaming the existing developers won't help. Doing the work will.
If you don't like it, extend it, fix it, or hire someone to do so. Don't dump your personal application requirements on community members who are just trying to share what they have.
So what you're really saying is "hey, you didn't have to pay for it, so just sit there and shut up about how bad it is. We don't care about your problems with it and we're not going to fix it. If you think you know so much, why don't you go fix it?"
Why, yes. That's exactly what they're saying.
And why not?
People ARE getting their very useful stuff for free.
The authors wrote it to handle the problems THEY care about.
It took a lot of work to get it that far. Making it easy to use and fitting it into a common interface style with a bunch of similar problems is a LOT of extra work. Satisfying every critic takes still more - and is often impossible.
If the problem YOU care about is ease-of-use, why DON'T you do something about it, rather than bitching? Source is there. Have at it!
Put in all that extra work, do a GOOD job on it, and the original author might just adopt it into the future mainline and give you major contributor credit. If he doesn't, publish your patches, or write a wrapper. Or FORK the bastard and port his future changes into your fork as he releases 'em. (Either that will be easy, or you didn't make your changes well, which might explain why he didn't merge your stuff.) If your version is enough easier to use than the original, yours will be the one that's widely adopted.
A little constructive criticism may be handy if the authors' designs are awkward to use but easily fixed. But when fixing them would take lots of work, constant whining without contributing labor is just a pain in the butt. And it's more likely to make the author drop the project than spend still more effort changing it to conform to YOUR preferences.
When somebody says "If you think you know so much, why don't you go fix it?" HE'S JUST INVITED YOU TO JOIN THE PROJECT!
Put up or shut up!
And people wonder why average users consider OSS proponents to be arrogant and egocentric?
What do you expect? These are people with exceptional skills who are working, not for free, but for ego-strokes. Of COURSE you get arrogant egocentrics. They're in it for themselves, to make software THEY like. If they make an exceptionally good tool that achieves wide adoption on its merits they've got a lot to be arrogant about.
Get used to it.
If you want it done YOUR way you have to PAY for it - in coin, in work, in resource contributions, or in encouragement. TANSTAAFL.
And if you're going to live off other people's charity, biting the hand that feeds you just makes you hungrier.
And 400 bucks for the primary unit, that realistically isn't that bad, especially if you have a monster of a computer system that has over 120 gigs of hdd space that needs backed up.
Yes, it is pretty bad. You can buy an external 250 GiB drive for $70 less than that with similar data transfer rates.
Or buy an INternal drive for still less, and a docking station that lets you install 3" hard drives in drawers and plug 'em into a 5" bay.
I can get a docking station and one drawer for (whatever modifier is current) ISA bus drives at Fry's for under $20, extra drive drawers for under $10 last time I looked. You absolutely CREAM the price of their base unit, and for $200 you can get plugins for far more than the 140M of their four-pack of 35s. And they don't come in little chunks that make you change media several times to do a backup.
And you're not limited to one manufacturer. (Even if the docking station flakes out and you can't find a replacement OR an equivalent system to move the drive to, you can always mount the bare disk back inside your machine or run a cable to it as an emergency measure.)
I'm currently engaged in putting them in all of my machines - not just for backup, but I'm making the primary drive removable, too. Then I can pull it out when upgrading or migrating, plug it into another slot as a secondary once the new system is built, and not have to sweat whether a runaway installer might trash the data on the old disk. Then I can archive it once I've ported what I need to the new system.
I know that I will never buy a car with RFID tracking capabilities built into it!
Your state will just put it in your license plate. Watch for it.
After all, they already hang a number on your car and require it to be visible - to eyes and to OCR cameras. Why not require it to be readable by radio, and save themselves some cost and flakeyness by replacing cameras with transcievers?
Look at how some people find picking up new [non-computer] languages really easy, and other people of similar apparent intelligence seem to have a complete inability do this.
I took a "Psych of Language Acquisition" course in college, back in the '60s - while trying to complete a language distribution requirement, hoping it would give me pointers. Instead it hexed me.
The theory at the time was that there were certain "critical periods" in brain development, for different aspects of language acquisition (phonemes, grammar, etc.), before which acquisition of that aspect was easy, after which it was darned near impossible. Having transferred from engineering (which didn't require language) to computer science (which in those days was under "math" in "Liberal Sciences and Arts", and thus DID require a language), I was starting language acquisition late - and was thus just past the last of the "critical periods" of the theory.
I had that class the hour immediately before the German class. So (regardless of the accuracy of the theory) I had to go straight from the class where I had to BELIEVE that theory (so I could reason from it to respond quickly to problem questions) to the one where I had to do what it said was impossible. Needless to say I didn't do well in German that term.
Later I found out that some big-name anthropoligists said that the theory was bunk. Later the theory was revised to state that if you learned the relevant aspect of a SECOND language before the critical period you were able to learn that aspect of more languages afterward. And the underlying mechanism of one of the hypothetical critical periods - phoneme acquisition - is now beleived to involve the death of neurons that are not used by the phonemes of the language learned. (So to learn another after the critical period you have to grow new neurons or retarget those you are using for other purposes, rather than simply preserve existing neurons that do the right job. Those who learn a second language early would thus preserve more of the nerves and their functions - including perhaps some responsible for keeping languages separate.)
So by this new model, people who learn a second language early and/or people who have exceptional nerve growth abilities would be able to learn languages later in life.
That would correlate to some extent with my experience: As an young child I "talked to cats" - mimicing their body language and agonistic noises in context. Learning German I discovered that I could easily make the labial fricative and uvular trill - which are not in English but which I had used for "hiss" and "purr" in my childhood experiments - but had the same trouble with the labial trill as other native English speakers.
So it would be interesting to know:
- How old you were on your bike ride.
- Whether you learned one or more than one language as a child.
| THE SUDDEN FLASH OF INSIGHT OCCURS WHEN solvers engage distinct
| neural and cognitive processes that allow them to see connections
| that previously eluded them.
maybe its the other way around -- perhaps the distinct neural
processes occur when one has the flash of insight.
That's my take, too. My impression is that the processing takes place for some time (and the mechanism is not wired for introspection of its operation, so you're largely unaware of it), producing one type of activity. Then, if a solution is recognized, there's a burst of another type of activity as the recognition is collected, checked, finalized, and/or propagated to other parts of the brain.
This seems to square with the MRI showing increased activity once the problem is given, but the EEG showing a characteristic burst of high-frequency noise just before the "AHA" is reported. Perhaps it's fair to interpret the MRI as seeing the first activity, and the EEG capturing the second.
A subjective and anaecdotal item: I get the impression that the (hypothetically pattern-matching) mechanism can call on other parts of the brain - more logical and more susceptable to introspection - at intermediate steps of the problem solving. For instance, about halfway to the solution of the "pine, crab, sauce" puzzle I remember thinking that they all looked food related and that the search should focus on food-related words. This step didn't seem to generate a full "aha", but it didn't follow from logic either. So perhaps a preliminary report of a potential weak correlation was reported out for logical checking and a "looks good, pursue it further" signal went back.
That might imply that the "aha" burst involves a rapid set of confirmations of fit on different parts of the proposed solution.
I've long thought of the thinking process as involving a world-model-building mechanism that includs pattern matcher(s) that hunt for connections and correlations, often finding false-positives, plus (hypothetically more sequential) checking process(es) that test the new correlations against the model and discard them as false or rearrange the model if they are accepted (possibly discarding previously accepted matches) - with pattern-matching assist to identify where checking should occur. Perhaps these results could put some rivets into such a model.
How about... Using Wine to emulate Windows to emulate Linux...
Probably wouldn't work. I doubt Wine (not)emulates that part of Windows.
But you should be able to do it the other way around: Run Windows apps in Wine in Linux in CoLinux in Windows.
Wouldn't be totally silly either: You could more ealisy compare the apps behavior under Wine and under Windows. (Though if it was sluggish or flakey on the Wine/Linux/CoLinux/Windows stack you'd have to confirm with Wine on native Linux to be sure it wasn't an artifact of running Linux under Windows.)
You mean the already available binaries bundled with Cygwin? Or coming up with a Win 32 copy of Mozilla? Or GCC? Or even the Gimp? Or do you mean Open GL apps? Or Vim? Emacs? Etc etc etc.
Nope.
Any existing linux binary. Any new linux binary.
Like that internal application that your company wrote whose source got lost.
Or the complicated one you got debugged and deployed on your department's native Linux platforms and you want to be sure runs EXACTLY THE SAME WAY on the boss' Windows box.
Relevant portion:
So even in Canada it's legal to have lock picks, crowbars, jimmies, paperclips, stethoscopes, etc. But it's a crime to be carrying them "under circumstances that give rise to a reasonable inference" that you intended to use 'em for no good, without documentation on you to the contrary.
Basically Canada has made explicit the assumption of guilt under such cricumstances. Down south here we have this Constitution that says our white-hats aren't supposed to do that. So they have to be a bit more subtle when they want to create the presumption of guilt. (Of course some of 'em do it anyhow.)
Basic point in either case is that you risk getting busted if you tote 'em around in places where you might be mistaken for a crook, unless you use 'em in your legal line of work and have papers on you to prove it. Even without Canada's presumption of guilt, having 'em in such circumstances is an extra indicator of criminal intent.
So the onus is on the individual to prove that they have the tools for a legitimate reason. That's pretty difficult to do unless you are a locksmith.
Yep. Look bad to a Canadian cop and you find yourself guilty until proven innocent - and you'd better have proof on you.
And even down here it's a good move to assume that you'd be treated to free room and board if you dress shabbily and hang out near locked buildings full of valuables that aren't yours with lockpicks in you pocket or a crowbar in your backpack.
But keep 'em in your safe at home and you're legal. It just becomes an extra kicker if they bust you for B&E, get a warrant, and search your place.
I'd like to see a true OOPs language like Smalltalk (OOPS are strong on prototyping) and UML (Strong on graphical modeling) combined with that tool mentioned awhile back that converts sketches to a refined diagram (Tablet PC's or Electronic Whiteboard). Throw in ad-hoc annotation capability and we are almost there.
Oh, boy. Now we can engage in rabid prototyping and have pretty pictures on the wall, too.
Bring up Smalltalk - or other rapid prototyping systems - and you demonstrate that the methodologies are leading you into the design-religion morass.
Rapid prototyping has been responsible for a plethora of project failures. This is because it consists of attempting to code without a design. That works if one person can keep the whole thing in his head, and breaks when the problem is large enough to need partitioning.
Rule of thumb: If rapid prototyping doesn't complete in 30 days, the project is to big for it. You must fall back on other design methodologies to succeed. Or you can continue for as much as a few years but you will eventually fail.
What you're talking about appears to be hanging automated tools on the rapid prototyping system to automatically infer the design document from the code. (Essentially, you're hanging the skin of a formal design methodology onto rapid prototyping in the hope of patching some of the latter's problems.) This is a cart-before-the-horse approach. But it also backs into the "self-documenting code" and "provable correctness" fallacies.
(It also reminds me - in style if not in substance - of a certain wild-eyed Smalltalk visionary's claim that software testing methodologies would have to improve until they could test his design in less than 30 minutes - because that's how often he changed it. B-) )
The key to robust code is to design it TWICE: Once as a human-readable spec, again as code. One must NEVER be automatically generated from the other - because debugging doesn't find bugs, only disagreements between specified and actual behavior. A particular implimentation of "cat" is VERY buggy if what you wanted was "ls". This is why correctness-proof tools aren't a panacea (and are misnamed): They work from a spec of what is correct, and writing a formal spec is ALSO a programming problem, subject to error.
It's OK for both the doc and the code to be in formal languages. It's OK for there to be a set of tools to perform part of the comparison between them automatically. But if you generate one from the other automatically, the only thing you can test is your generation tools. If it doesn't do what was intended that won't show, because the spec and the code will both prescribe the same "broken" behavior. And it's OK for a human to work from a spec toward code - because he'll be giving critical thought to the spec as he codes, and thus tends to discover spec errors.
But it's important for the two languages to be as different as practical, to put the designer and the programmer (especially if they're the same person) into different mind-sets when writing each. The more different they are, the more likely it is that problems will be discovered during the generation of one or the other. (This is why correctness-proof tools are useful despite being misnamed.)
In a real-world project the code and the design co-evolve to a significant extent. When you find a bug it's usually in the code (because the design went ahead of the code and had much standalone debugging). So you fix the code. But sometimes writing the code exposes a bug in the design. Then you fix the design. When you're done the code and design agree - and they're both near-perfect because the final versions of both withstood the entire trial-by-fire and many-eye inspection.
Your analogy of software security to (presumably) physical world "invasion" tools (e.g., lock picks, etc.) causes me to make a prediction. The prediction is that, like lock picks, the use and possession of software security tools may in the future be licensed and regulated.
Last I heard, the possession of lockpicks was generally NOT regulated - no matter what the locksmithing industry would like you to believe.
Like crowbars, the crime is possession with intent to use illegally. (Unlike crowbars, it's a lot easier to show intent to use a lock pick as a burglary tool.)
However IANAL and have not studied this issue closely. (Also it's state level issue, so both the laws and precedents vary.)
So reverse engineering is not a problem in this case. In fact, it's not unlikely that AMD simply handed them the documentation.
Reverse engineering is NEVER a problem. The very concept that it MIGHT be is recent - and driven by propaganda from the software industry.
Historically, industries have reverse engineered nearly everything: Cars, looms, what have you. (Auto compaines, for instance, have entire DEPARTMENTS to disassemble and reverse-engineer their competitors' products.)
You can patent an idea - which gives you a lock for a number of years on using it in a commercial product or process. But that immediately exposes it, and releases it to the public domain once the time is up.
Alternatively you can keep it secret, and hope the secret stays secret and nobody reinvents or reverse-engineers it. But once the cat's out of the bag you have no protection whatsoever. If you show the secret to an employee or business partner, and they leak it or use it beyond the limits of the contract, you can sue THEM and enjoin them against further disclosure. But if the "secret" has spread beyond catching, or if it is rediscovered/reinvented or discovered by examining a product you sold, tough luck!
Software companies have tried to stretch trade secret via ELUAs claiming you're a "business partner" rather than a purchaser of a product, and thus contractually forbidden to do reverse-engineering. And they've tried to stretch copyright similarly, claiming you have to copy it to use it to reverse engineer and that's forbidden by your license (first-sale doctrine be damned). But (except for the DMCA, which has yet to be adequately tested) there's essentially no foundation in law for these claims.
Or at least that's how I (who ANAL) read it.
I think we can safely guarantee the condition of just about any cargo which hits the moon at that speed.
Implying that it will be destroyed, right?
Not necessarily.
This is just an extreme case of the "egg drop" problem used by the UofMich ingineering school ion their packaging class one year (and no doubt other engineering schools from time to time).
Problem: Package a raw egg with less than (x) grams of packing material so that it can be dropped from the roof of the four-floor engineering building to the concrete below and arrive intact.
A number of solutions were tried. Some I remember hearing about:
- Suspended inside a ball by rubber bands.
- bubble wrap variants
- foam peanut variants
- Stuffed into the top of a stack of styrofoam cups with kleenex, fins added to last cup to insure bottom cup arrives end-on. (Energy absorbed by friction of cup stack cracking and collapsing).
(That last one was a winner and led directly to the nested-sheetmetal protectors you sometimes see on freeways in front of overpass support piers.)
Then we have NASA's recent "airbag" landing on Mars.
4K MPH is a bit extreme. But you've got a LOT of space to, for instance, blow up a LARGE airbag/bubblewrap analog, and plenty of time to do it.
Encapsulated electronics, and even moving parts if packed correctly, can handle thousands of Gs easily. (Think about MOOG's final test for his synthesizer components: Three feet to a cement floor, must stll be fully operational and still correctly tuned afterward.) 4000 MPH = 5867 fps. Bullets are routinely accellerated to that velocity in a few feet without distortion from the g forces involved (though that is a bit extreme), and bullets with moving parts (such as spin-armed explosive rounds) to maybe a couple thousand FPS ditto.
So figure inflating maybe a 50 foot radius cluster of 'way thin kevlar balloons or bubble-wrap with aerojell just before impact, and taking maybe 20kg at the peak of decelleration, and it should be survivable.
How is PlayFair different from DeCSS?
They're close.
But DeCSS got leaked when it was still a stand-alone module developed within a windows application. This weakened the argument that the purpose was to generate a Linux player. (It was, and this was a convenient intermediate step, but it still weakened the argument.)
PlayFair is a complete application which refuses to operate unless you have the appropriate license for playing the content, and only performs conversions that all aid recognized fair use. Since it's open-source its guts COULD be ripped up and rehacked into a pirate tool. But as distributed the functionality is strictly within the bounds protected both by copyright law AND the DMCA.
Apple has not come close to proving that a law has been broken [...]
I can only conclude that OSDN are either lazy, scared of Apple, or have interests in Apple.
I conclude something else.
SourceForge is a major resource for FOSS, serving as the project host and canonical version maintainence site for a large number of projects.
Fighting for this particular one, winning, and establishing a precedent, might be useful. But it would be DAMED expensive, and DAMNED risky. A loss - or even an expensive win - would take out the resource.
And fighting it is not NECESSARY. Because the project is already multiply mirrored (no doubt by a large number of people who realized this would be coming as soon as the project was announced) and officially rehosted at one of those mirrors, beyond the direct reach of US law.
The secret to winning a war is to fight it on your own terms. RIAA and its cronies are like a small herd of elephants. FOSS is more like a prarie-dog colony - or perhaps several hives of army ants. One side has great strength, the other great numbers and diversity but little strength in any one place. How should the diverse side fight this battle? One-on-one fight? Or "whack-a-mole"?
"The Colonists win the toss. The British have to wear red uniforms and stand in rows. The Colonists get to wear brown and green and shoot from behind trees and rocks."
No, it's not fair use.
Yes it is. See below.
When you buy music from Apple you are buying it under a specific contract and by buying it you are accepting the terms of that contract which limits the use of the music. Don't like the terms, don't get it from Apple.
Flip this around and imagine that I decide to circumvent the GPL by taking a piece of GPL software and using its source in piece of closed source commercial software. Wouldn't like that now, would you?
Neither Apple's contract nor the GPL trumps Fair Use. Copyright doesn't prevent doing what you want with your own copy within certain limits. Copyright doesn't prevent proprietary software vendors from incorporating parts of GPLed software in proprietary products, again withing certain limits.
In the case of music, the limits allow making format change copies for personal use and giving away or selling the original if you don't keep a copy - but prohibit giving away or selling clones (or the original but keeping a clone), giving public performances, or doing a "cover" version in violation of the license terms.
In the case of GPLed software the limits allow small snippets of code to be incorporated or the functionality to be replicated with newly-written code, but prohibit copying of substantial sections, wholesale distribution, or straightforward translation, in violation of the license terms.
DMCA is a whole new can of worms, creating a catch-22 to block the exercise of fair use rights. This will eventually get shaken out in the courts, one way or another. But don't hold your breath waiting for that. It might take decades, or generations.
Speeder not the only one punished... ...but also everyone behind him/her.
It's San Francisco. Individuals are not responsible for their actions. Guilt only applies to groups. They're all driving cars, so they're all equally guilty. And they all need to get over their love affairs with cars and use public transit. (Even if it doesn't go where then need to go, or takes several hours to replace a 10-minute car trip and costs far more, or stops running after 6 PM and doesn't restart until Monday.)
And shit is Shinola.
"It seems like you're trying to exploit a security hole. Would you like help?"
Whoa! Deja Vu!
It's almost echoing this recent thread in the Kernel Panic strip.
5MW is good for 10,000 homes, so a house in Scotland only uses 500 watts of electricity?
Rule of thumb for the US is 1 KW/home "fleet average B-) ". A LOT of that is either air conditioning or (in the few remaining ones from the "it's going to be too cheap to meter" era) electric heating and/or electric water heating, in the houses so equipped.
Resistance heating is HORRIBLY expensive in terms of power consumption. (More than a factor of three inefficiency compared to burning the same fuel to apply heat directly.) Air conditioning comes in two forms - heat pumping (also very energy intensive) and evaporative (only usable in arid areas, and an allergy and toxin problem, so much less common).
Scotland has a very mild climate compared to the US. It sits at the end of the gulf stream, which provides heating that nicely compensates for its latitude and moderates its climate dramatically. (For an extreme of this effect look at "Summer Isle" - just off the coast on the gulf-steam side and growing palm trees.) The US is spread out over a continent, with considerable variation in latitude and altitude - and thus temperature. The mountains on the upwind side also dump the moisture out of the prevailing winds and their heat of vaporization into the atmosphere, creating the western and soutwestern deserts.
No, I wouldn't be at all surprised if the US averages twice the domestic electric consumption of Scotland.
This is all part of an alien conspiracy to bring the moon crashing down on us! Awaken to the truth before it's too late!
Actually, tidal friction slows the rotation of the earth and raises the orbit of the moon. Extracting tidal power will increase the friction and thus the rate at which this happens.
(Of course if there WAS a chance of bringing down the moon that would make for QUITE the "environmental impact".)
This is mostly about consolidating control of not only the data center but the desktop within corporations.
IMHO this, like the investment in Apple, is about Microsoft trying to head off future legal trouble.
Sun and Apple were essentially the only direct commercial competitors to Microsoft. Right now Sun is dying - and Microsoft has a track record of screwing them. If Sun goes under Microsoft gets bit big-time in the NEXT anti-trust suit.
So just as they did when Apple was about to fold, MS gives 'em enough money to keep 'em afloat.
People have been saying their payments to Sun are peanuts. But they're a LOT of peanuts: MS just gave Sun one out of every 25 peanuts they have. There are only two reasons for them to do that:
- To make even more money later as a result.
- To avoid losing even more money later as a result.
There's no WAY this is going to make them more a couple of billion any time soon. So it's got to be avoiding the loss of more.
One moment they are advocating how big linux and OSS movement is, the next moment backhand deal with MSFT.
Sun has a long history of vacilating on openness.
They did it with SPARC. They did it with their OS. And so on.
I jumped to Linux from Sun primarily because I wanted to do some HW/SW hacking. Linux (and the BSDs) are open, as is the hardware they run on. The sofware is certain to stay that way, and the hardware likely either will or will be hacked. But it's just too much of a pain trying to get HW and SW info on Sun/Solaris platforms.