Section 3 "unauthorised modification of computer material" being the relevant element. There isn't, I think, an existing case which exactly mirrors this, but it is similar to the matter of "time locks" in software (where a program disabled itself after a given time). For a long time after the passage of the act, lawyers theorised that such locks might be illegal in some circumstances; the prosecution of Alfred Whittaker in Scunthorpe Magistrates Court in 1993 showed that it could be. But crucially in Whittaker, the locks were unknown to the customer (the company on whose computer the software was installed) - I don't think anyone thinks that time-limited trialware ("this software will stop working in 28 days unless activated") is illegal.
So whether FDTI are in trouble will depend on what expectation someone might have when installing the new driver (where the court assumes they actually read the licence screed). If the expectation was solely that it would improve their system or do nothing, they weren't giving consent, and FDTI may be found to have breached section 3. If the licence unambiguously said "this update will detect and disable fake or work-alike products without further interaction", they're probably fine. Likely the wording is much less clear, which is what keeps lawyers in jobs.
If all the bricked chips are counterfeits (that is, they have fake FDTI markings and have been passed of as real FDTI products), the Fiscal is probably going to say that a prosecution isn't in the public interest. The authorities, often working with trademark owners, have routinely seized counterfeit goods from unknowing individuals, with no compensation; they may argue this is an analogous case (sweeping analogies is what keeps judges in jobs). But if someone has been making FDTI workalike clones that aren't pretending (to consumers) that they're the FDTI product, their customers would have a better chance of twisting the Fiscal's arm.
Most Russian launchers are delivered just this, including Soyuz, Proton, Energia (including Energia/Buran). They're horizontally integrated (as opposed to the VAB's vertical integration) and placed on a cradle. The cradle is moved, on rails, to the launch facility, where the cradle boom tips the launcher vertical and it's integrated with the launch gantry equipment and (excepting at least Soyuz) the hold-down system. An exception to this is Soyuz operated from the ESA site, which are vertically integrated on the pad using a giant mobile building - once the integration is complete they open the huge doors on that and the building rolls backwards (I think on rails) and moves back far enough for it not to be damaged by the Soyuz' launch.
The most elegant solution to the calendar I've seen is JRR Tolkien's (yes, him) Shire Calendar:
It's fully conformant with the astronomical realities (no magical even-divisions or date fudging necessary)
There are still 12 months (so no weird decimal months, no 34th of Thermidor bollocks). You can stick with the familiar month names (rather than Tolkien's Hobbity ones)
Each month is 30 days long (simplifying accounting, pay calculations, holiday accrual etc.). No pointless variation, no mnemonics.
Year on year, a given month always begins with the same day of the week. Even for leap years. So if you were born on a Tuesday, your birthday will always be Tuesday.
The clever part (which allows all the other stuff to happen) is there is a winter festival holiday (2 days) and a summer festival holiday (3 days normally, 4 in leap years). These aren't week days and aren't in a month - they're special. So e.g. Christmas doesn't change between sometimes being in the weekend, or adjacent to the weekend, or midweek - Christmas is always in the same place. I know I always get disoriented around Christmas - Christmas already seems like a special day which doesn't resemble a Thursday or a Sunday or whatever - the Shire Calendar is just a realistic expression that it's not a weekday, and that it shouldn't be regarded as one. And the first day back at work after Christmas is always a Monday.
The winter and summer festivals are pretty consonant with common practice in many countries anyway. Move Christmas into the yule holiday (Jesus wasn't born in December anyway, so it's no less Biblically correct than current practice). Many countries have a midsummer festival or summer bank holiday and US independence day can be celebrated then.
You only need one printed calendar (not the 14 different types we currently need) - you just score off the leap year or not.
Its easy to fix the locations of other festivals, like Thanksgiving, and then you get a perfectly consistent gap between e.g. Thanksgiving and Christmas
From a software perspective it's a wash - 2 more mini-months need to be handled, but less bother with differently lengthed months and much easier day-of-the-week calculations.
Technology companies are pretty good about properly integrating their marketing and public relations efforts into the business proper. So if they need to do a safety recall the PR people are involved in the process; a decent PR guy can turn "the XYZ-5000 sprays customers with burning acid" recall into "XYZ really cares about its customers, and as a lovely fluffy precaution we're fixing all our XYZ-5000s, even though most of them are perfectly super and don't experience moderate thermal variances". Engineering, QA, customer relations, finance - every department doesn't get to communicate with the public (or do anything that's obviously going to end up being public) without someone in PR there to make sure the message is put out right.
Legal departments, by dint of (often broken) corporate org-trees are a notable exception to this. When they see a problem, they fix it the lawyer way, and the rest of the company never knows until after the fact. In olden times of yore stuff like this was trivia between one legal office and another, and only the most nebbish of corporate historian ever know why a product changed its name or wasn't orange coloured any more. So the lawyers behaved as they always did, striking as quickly and as hard as they could, writing letters as outlandishly vitriolic and court pleadings as wildly exaggerated as they felt they could get away with, knowing that things would stay on the downlow and whatever happened only the outcome would matter to anyone.
They didn't consider that, if you sent someone a demand letter, the first thing they'd do is tweet about it to their entire customer base (which turns out to be a big proportion of your customer base too), and post the letter (with all its wild and crazy claims) on the internet, for everyone to point and laugh at. If it's the all-too-common shot across the bows (rather than a serious attempt) you risk looking like a rather unhinged bully.
Like it or not (and the lawyers don't like it, and decorate their broadsides with all kinds of "if you publish this letter we'll sue to for that too" stuff) everything anyone in the corporation does reflects on the whole outfit. The PR folks should be in on the ground floor with anything like this. They don't get to veto every lawsuit or every letter, but they can put a choke-hold on the stupid. Right now Zenimax's PR guy has his head in his hands; I'll bet the first thing he knew about the whole affair was when he read it online, and he'll spend next week fighting fires and soothing angry faces. Notch probably won't change the name, but if he does that's just another news cycle of bad PR for Zenimax.
They're not thinking about this for what we're currently call a "phone". They're looking at very small form factor devices which keep their data in the cloud, are configured by another (arbitrary) device which talks to the same cloud, and which make either sporadic or continual data connections with whatever available networks they find, to keep up to date. Imagine very small devices (wristwatches, eyeglasses, earplugs) with 802.11/UMTS/WiMAX radios (which use a mini-sim to identify themselves to whichever network they encounter). And they're thinking about these things as universal identifiers and payment tokens.
Right now you go running with an iPod. Instead you'll have a iPlug, a pair of little in-ear headphones, but with no cable and nothing strapped to your arm. You set up your music program on a tablet, and it seamlessly syncs. You run further than you'd expected, so the iPlug connects to the network and downloads more music. Miles from home your knee gives out. You touch the iPlug and say "taxi". A taxi comes (sent by Apple to the location the iPlug knew; Apple gets a dollar from the taxi fare, which you pay using the iPlug).
You have a iSim unit in your iWatch. You're thirsty, so you touch the watch and say "coffee shop". The watch face shows an arrow to a nearby one, and the distance, and walks you there. Apple gets a dollar. You buy a drink with the iSIM as a payment token (Apple gets 30 cents) and sit down at a table. The table's surface is an active display; it talks to your iWatch and opens a connection to your account in the iCloud. Your personal news appears, your emails, your documents. You do some work, browse some stuff, and when you're done you stand up and the table blinks off. Things will be as you left them when you next peer with an active display - at home, in the car, on the train, at the office, on the beach.
All of this stuff has been done, in various disconnected ways, already. You can pay for stuff with your phone, in some places. Most Europeans (well, Brits at least) have smart cards in their credit cards. You could hotdesk 10 years ago with a Sunray (kinda). You can unlock doors with a Dallas button token. Having super-cheap super-light totally ubiquitous networking makes the whole thing join up into a compelling, powerful, system.
My company recently bought a used copier/scanner/printer, which had supposedly been reconditioned and cleaned. It included a "document server" feature, whereby jobs could be scanned to its internal disk (or print jobs could be stored in the printer for later printing). The salesman who sold it to us had helpfully left scans of his current account statement in the document server, together with some placating letters to other customers. After thinking about what uses we'd actually have, I decided just to turn the document server feature off for everyone. I did leave the deferred-jobs part on (as it's useful when someone is printing on weird stock or printing something confidential) - thus ensuring that anything left on the copier (the company is now defunct, the copier presumably resold) is guaranteed to be juicy.
Re:Why can't the movie theatre _tell_ the phone
on
Polite Cell Phones
·
· Score: 1
[urgh, should have previewed]
Rather than guessing we're in a movie theatre (which is what this amounts to) or places using cell-phone blockers, why can't someone implement a simple scheme to _tell_ the phone not to ring?
Of those phones which do ring in an inappropriate place, the owners of the great majority have simply forgotten to turn their phone off (they're forgetful, not sociopathic). Movie theatres, concert halls, libraries and other please-keep-quiet places could have short-range radio equipment inside which sent a "this is a quiet zone" signal. You'd program your phone (and it would come programmed by default) that when it was receiving that signal it would go onto the vibrate-only ring preference. When the signal was lost, it would revert to your default. So when you entered, and when you left, there would be no need to remember to set the phone correctly (the nagging ads always remind me to turn my phone off, but very often I forget at the end and leave my phone off for the remainder of the day). Similarly noisy places like train stations and airport concourses could broadcast a "this is a noisy environment", which your phone would typically interpret to mean that it should use a loud, shrill ringtone.
There are people who legitimately (and quite reasonably) should have working cellphones in quiet places - doctors on homecall, standby emergency workers, out-of-hours plumbers, parents who've left their kids with a teenage sitter. Enabling these people to use their phones sensibly while largely preventing accidental annoyances would be a great (and surely hot difficult) idea.
Phones should, incidentally, have an "answer with hold" button. So a doctor in the movies whose phone rang (silently) could take it out, notice that it's the hospital's number, and push "answer with hold". The caller would get a short recorded message saying "this person is aware of your call, and will be with you shortly - please hold" - that way the doctor can take the call, but doesn't have to talk into the phone until they've walked into the theatre lobby, where they can take the phone off hold and talk.
Why can't the movie theatre _tell_ the phone
on
Polite Cell Phones
·
· Score: 5, Insightful
Rather than guessing we're in a movie theatre (which is what this amounts to) or places using cell-phone blockers, why can't someone implement a simple scheme to _tell_ the phone not to ring?
Of those phones which do ring in an inappropriate place, the owners of the great majority have simply forgotten to turn their phone off (they're forgetful, not sociopathic). Movie theatres, concert halls, libraries and other please-keep-quiet places could have short-range radio equipment inside which sent a "this is a quiet zone" signal. You'd program your phone (and it would come programmed by default) that when it was receiving that signal it would go onto the vibrate-only ring preference. When the signal was lost, it would revert to your default. So when you entered, and when you left, there would be no need to remember to set the phone correctly (the nagging ads always remind me to turn my phone off, but very often I forget at the end and leave my phone off for the remainder of the day). Similarly noisy places like train stations and airport concourses could broadcast a "this is a noisy environment", which your phone would typically interpret to mean that it should use a loud, shrill ringtone.
There >are
Phones should, incidentally, have an "answer with hold" button. So a doctor in the movies whose phone rang (silently) could take it out, notice that it's the hospital's number, and push "answer with hold". The caller would get a short recorded message saying "this person is aware of your call, and will be with you shortly - please hold" - that way the doctor can take the call, but doesn't have to talk into the phone until they've walked into the theatre lobby, where they can take the phone off hold and talk.
It's the brokerage company's fault, and they should bear all the responsibility. This problem could be mitigated by better software design (and the bad design of the software is 100% the fault of the brokerage, who could have specified something a whole lot better). The fact that the brokerage is allowed to run software this permissive is, in turn, entirely the fault of lax regulations in the exchange.
Any system which relies for its safely on a person "being careful" is doomed, as humans are fallible and make mistakes, particularly in high-speed, high-stress environments like financial trading desks.
One way this problem could have been "engineered out" is:
Define a "trading limit", which is the maxiumum difference between the stock's current price and the price at which a trader may buy or sell. Maybe this is 5% (it depends on the volatility of the stock, and perhaps on the brokerage's trading strategy)
Brokers can only perform transactions within this range; any attempt to trade outside this range is rejected by the software. In practice most trades are much much closer to the trading limit, but it's nice to have a wider limit than one would normally use, so the brokerage can react swiftly to market events.
If, in an exceptional circumstance, a broker feels he needs to transact outside that limit, he places a special request (using the software). The request is relayed to several senior staff (probably senior brokers) and if they approve it, the transaction can complete. Optionally they can approve a temporary widening of the trading limit (i.e. for more than one transaction, but still a limited period such as an hour).
Tune the parameters (trading limit, mechanism for requesting wider limit, duration of it) so that the company retains most of its ability to react to volatility and so that escalations to the senior committee are rare (no more than one a day - more frequently and you risk them automatically rubberstamping without thinking properly about the matter)
This doesn't entirely remove the problem, but it means the damage that can be done is one or two orders of magnitude less than would be possible in a system where the trader has total liberty.
In addition to protecting against inadvertent trades, it also protects the brokerage against a trader who is malicious, depressed, drunk, or temporarily insane.
I'm really astonished that something like this isn't done already, and astonished that it's not mandatory.
Actors have a similar solution already. They just need to go to the Anakin Skywalker School of Acting, where actors are trained to drain their voices of even the tiniest trace of nuance, inflection, tremor, or emotion. Soon they're able to speak even the most emotionally charged lines (e.g. "I don't like sand") with the steely monotone of a T-800 terminator with a flat battery.
Some of the images used by Google are NASA Landsat 7 images, and these indeed aren't copyright. Others are USGS aerial photography and black and white USGS satellite imagery (which I think are declassified corona data) and these aren't copyright either. But google also uses higher resolution satellite images from commercial providers like Space Imaging's IKONOS platform. These are copyright (although Google seems to use lower-resolution versions of these, due surely to cost).
Anyway, the image in the NEWS.com.au article is USGS aerial photography, and the same redactions are done in the current data drop (as available via NASA's World Wind system) - so this particular censoring happened before the data got to google.
Indeed, there would be no point in censoring the commercial imagery used by google for the reactor in question, as the enemies/terrorists/Bad Guys (tm) could order the imagery themselves, presumably though some front company. So the aussies would need to persuade several vendors of commercial satellite photos, including US, European and Russian providers, to censor their images.
Note that Space Imaging don't (or didn't, at least) have a blanket list of sensitive US properties they won't photograph - the happily supplied the Federation of American Scientits with lovely images of Area 51: http://www.fas.org/irp/overhead/groom.htm
So complaining publically about google is entirely counterproductive; they're just standing on their own stumps;)
You're correct. The grandparent post is of Tonopah Test Range, not Groom The square residential block shown is the "mancamp" facility, a mile or two from TTR. The irrigation circles so suspected by the grandparent article are outside the Nellis Range. Tonopah is was the original home of the F117 after it moved from Groom, and continues to be part of the Nellis Range testing complex - those markings on the ground are part of the system of test targets used by USAF pilots training at Nellis. The "bomb craters" shown on the grandparent's site are depressions in the ground caused by underground nuclear testing in the northern Yucca Flats area of the Nevada Test Site. None of this is particularly secret, none of it is terribly near Groom, and none of it is Area 51.
The worst thing about planets is all the boneheads you have to share one with. Just as soon as you've gotten your patch just how you like it, some twit five thousand miles away sets off his A-bomb, releases his homebrewed filovirus, or just dumps his industrial crap in your shared air and water. In a modest sized artificial environment, no-one can dodge the consequences of his actions (and if anyone tries, you can deport them back to the glowing farty shithole the Earth has become).
Some reading from the "planets are for lusers" squad: * Michael Swanwick's "Vacuum Flowers" * Marshall T. Savage's "The Millennial Project: Colonizing the Galaxy in Eight Easy Steps"
Well, an elementary JVM is trivial, but a half-decent one has some harder stuff. Assuming they'll want to get Harmony up to the standard of Apache-httpd and Apache-tomcat, the JVM component will be a big job too.
The bytecode loop and elementary classloader are indeed straightforward (which is why there are so many of them hanging around), and doesn't really get harder between a barely-working JVM and a decent one. Lots of other stuff, however, does:
A dumb, blocking, non-generational mark-and-sweep garbage collector is fairly straightforward (handling blocking and native methods wrt GC is a complication, if a manageable one). But for a box serving lots of connections on a busy website, you don't really want half second long pauses while the GC sweeps the whole memory. You really need a generational collector, and you really want one that's either non-blocking (yes, that's hard) or resumable. The nice thing is that the GC is fairly self contained (not entirely, as it interworks with synchronisation and the native method interface) and there are lots of university research groups who have done lots of research on GCs (for java and other languages) so it should be possible either to pick up some research collector or farm the work out to some eager masters students.
Efficient management of native synchronisation resources has an important effect on scalability. Mature JVMs go to great lengths to marshall the number of native synchronisation primitives the JVM instance uses (e.g. with some kind of mutex pool, assigning an OS mutex to a java one only when it is in scope). They can work without this for a while, but it needs done eventually. I see Doug Lea is onboard, and this kind of stuff is Doug's meat-and-drink.
The verifier is hard to get right. Sun's one is the product of careful design and then of several analyses by third parties. For example, one univerity wrote a verifier from the JVM spec in a formal language (Z or something) and then threw millions of randomly generated program fragments at their one and the Sun one. Where the two differed, the group analysed the program in depth. From this they found dozens of cases where the two verifiers differed materially; most were due to different interpretations of the JVM spec (which, one hopes, resulted in the language of the spec being tightened) but about ten were nontrivial holes in the Sun verifier. Last time I was involved with this (a few years ago) Sun insisted that all Java licencees (even those who had written their own JVM etc. entirely from scratch) run the Sun verifier. Luckily, the verifier is like the GC - it's a subject of ongoing academic research, so there are universities who might be persuaded to do the heavy lifting. And for a trusted enterprise setup you can do without the verifier anyway (it's really only needed for untrusted mobile code like applets or JINI things).
But the really big task is dynamic compilation. A bytecode-interpreted system isn't credible for any real application. A JIT will do, at the expense of sluggish performance and drastic memory-munching. A real hotspot-like smart, self-monitoring dynamic compiler is really necessary for a quality JVM. I guess the Harmony folks will spend a lot of effort here, as it's a lot of work and its too tightly bound to your JVM internals to either farm out or to allow you to easily take something off the shelf.
Still, I hope I've not sounded too negative. It's all doable (python and mono do most of this stuff between them, neither with a vast team) and the lack of a free or open JVM has been an uncomfortable gap between LAMP and tomcat for too long.
Heck, maybe it's just a strategy to get Sun to open Tiger sooner rather than later.
You know, I was just looking at one, thinking "hmm, that looks kinda >compressed<" (particularly when one is used to looking through WorldWind). You've explained it perfectly, thanks.
The images appear to come from two sources. Non-urban US areas are NASA Landsat-7 images (which, as works of the US Federal government) as public domain. Some urban areas (I looked at Mountain View, CA) are USGS aerial photography montages. Again, as works of the US Federal government, these are public domain too (and available at higher resolutions in WorldWind). Google can only claim copyright over something when they've made a non-trivial contribution toward it (republishing isn't enough). The landsat images have been well montaged and registered, I think by Keyhole (that's difficult to do so well, requiring technique and skill, so that's probably copyrightable). As far as I know, the USGS photos are montaged, registered and adjusted by the USGS, so quite what Google think they've contributed to that is unclear.
I had a similar experience with a rental VHS copy of David Cronenberg's "Videodrome". The rental copy (conspiring with a nasty oxide buildup on the cheapo player's play head) began to degrade about half way through, getting grainier and noiser as it went on. By the end it was all snow. Given the subject of the movie, and the preponderance of "distressed" video deliberately present in the original, I was convinced that this way entirely intentional. For _years_ I'd tell people what a clever, original idea this was, having a movie about video messing with you that itself became messier and messier until it vanished entirely. It wasn't until I rented it on video that I discovered the truth. And dammit, I claim my version was _better_:)
Re:What a joke
on
Top 50 DVDs
·
· Score: 3, Insightful
What is Memento if not the first well-known movie in years to literally require at least two viewings!?
Indeed, it really does require that second viewing. But once you've truly figured out what's going on, and the forward-backward conceit, the third viewing is downright dull. With the tension and ambiguity resolved, Memento turns into a movie with negligible plot and incredibly flat characters. I loved it the first time though, but it has no long term watchability.
Fight Club, on the other hand, is confusing and clever in the same way Memento is, but has far more staying power; there are so many little clues and corners and brilliant lines that it's still entertaining and fresh after a dozen watchings.
Haven't they had the audio part of this (figuring out where gunshots come from) in Redwood City, CA, for years? I believe they do (or did), but that it went bonkers every Cinco de Mayo.
It doesn't make much, if any, difference to slashdotters like you and I. But to AOL it's potentially a very big deal indeed. It'd be foolish to infer too much about AOL's internal thinking from one technology offering (particularly about a company so prone to factionalism as AOL) but this might imply that at least some part of the company is maneuvering for a firefox-based AOL client to be the standard.
I think it's likely AOL would like to move to a Firefox client, as there are several real business advantages for them, including
They bear the brunt of the support-call cost for a subscriber's entire PC (particularly for viruses, spyware, pagejacking, and increasingly fraud). Moving their userbase away from IE would surely save them a fair amount of this, and that's real dollars and cents.
No-one wants their business to be dependant on Microsoft, particularly folks like AOL who are locked in competition with MS on a variety of fronts. The more they can extricate themselves from said dependency the safer they'll feel, and even a partial extrication today is better than none, and can be a stepping stone to dumping MS altogether. That's no wide-eyed open-source idealism, it's cold hard corporate survivalism.
For a vertically-integrated provider like AOL, firefoxes UI framework and ease of extension makes for an attractive platform.
The fly in the ointment for them is website compatibility. Sure, most sites do indeed work fine, but there's a sufficiently large number that don't to make AOL switching untenable. A number of the folks I've successfully switched to firefox have migrated back, particularly because either their bank, airline, or corporate portal have been IE only.
Now, AOL has a full list of the sites their customers visit, and can easily compile a list of the major ones that need IE. They can build this list into an integrated firefox-IE browser, so that it switches to IE for those "legacy mode" sites seemlessly. That may well be what this netscape is - a test version of a "smart-switching" AOL client.
If they wanted to (although I can't see as much business case for them to want to) AOL could then put pressure on those sites that don't work with firefox to fix their issues. THey can threaten to start popping up little windows saying "legacy mode support", "backward-compatibility mode", or "old-style technology mode", a mark of Cain the site in question would rather avoid.
But most of all it's an option. In business, an option is an advantage even if you don't take it - in this case it's a great stick with which to beat Microsoft in future negociations. So it's a smart move to make, and a scary (for MS) technology for them to have - it's what MS fears the most, a smooth migration path away from MS.
Wikis are fantastic for collaboratively building documents, and their potential in professional applications is great. But a wiki in isolation isn't enough, and building your collaborative system solely on a wiki is going to be an unpleasant experience, at least in points.
Wikis are rotten for threaded conversations - stuff gets overwritten, moved around, refactored, deleted, and it can be horrible to follow a thread (essentially everyone has to follow a layout which indicated the thread structure). This is a job for a message board or mailing list - to make this work properly with the wiki, you need single-signon and workable links between the board and the wiki (plain http links are okay, but smarter linking would be better). Ideally the board will support the wiki syntax, or will support embedding wiki "pages" into posts.
Also, it's hard to automatically syndicate or publish a wiki, either via RSS/ATOM or a mailing list. MediaWiki has a teeny bit of syndication support, but not for ordinary content pages. This issue is when to push a set of changes
Integration with your corporate email system, bug/issue-track system (or CRM system), maybe instant messaging system, or maybe VCS system would also be a great thing. This integration is really the "thesis" of Lotus Notes - that collaboration takes places in many forms, and that rather than force users into one paradigm it's better to make all the modes work smoothly with one another; it's really a damn shame Notes hasn't lived up to the promise this integration has.
Slashdot Mirror
Section 3 "unauthorised modification of computer material" being the relevant element. There isn't, I think, an existing case which exactly mirrors this, but it is similar to the matter of "time locks" in software (where a program disabled itself after a given time). For a long time after the passage of the act, lawyers theorised that such locks might be illegal in some circumstances; the prosecution of Alfred Whittaker in Scunthorpe Magistrates Court in 1993 showed that it could be. But crucially in Whittaker, the locks were unknown to the customer (the company on whose computer the software was installed) - I don't think anyone thinks that time-limited trialware ("this software will stop working in 28 days unless activated") is illegal.
So whether FDTI are in trouble will depend on what expectation someone might have when installing the new driver (where the court assumes they actually read the licence screed). If the expectation was solely that it would improve their system or do nothing, they weren't giving consent, and FDTI may be found to have breached section 3. If the licence unambiguously said "this update will detect and disable fake or work-alike products without further interaction", they're probably fine. Likely the wording is much less clear, which is what keeps lawyers in jobs.
If all the bricked chips are counterfeits (that is, they have fake FDTI markings and have been passed of as real FDTI products), the Fiscal is probably going to say that a prosecution isn't in the public interest. The authorities, often working with trademark owners, have routinely seized counterfeit goods from unknowing individuals, with no compensation; they may argue this is an analogous case (sweeping analogies is what keeps judges in jobs). But if someone has been making FDTI workalike clones that aren't pretending (to consumers) that they're the FDTI product, their customers would have a better chance of twisting the Fiscal's arm.
Most Russian launchers are delivered just this, including Soyuz, Proton, Energia (including Energia/Buran). They're horizontally integrated (as opposed to the VAB's vertical integration) and placed on a cradle. The cradle is moved, on rails, to the launch facility, where the cradle boom tips the launcher vertical and it's integrated with the launch gantry equipment and (excepting at least Soyuz) the hold-down system. An exception to this is Soyuz operated from the ESA site, which are vertically integrated on the pad using a giant mobile building - once the integration is complete they open the huge doors on that and the building rolls backwards (I think on rails) and moves back far enough for it not to be damaged by the Soyuz' launch.
The most elegant solution to the calendar I've seen is JRR Tolkien's (yes, him) Shire Calendar:
Technology companies are pretty good about properly integrating their marketing and public relations efforts into the business proper. So if they need to do a safety recall the PR people are involved in the process; a decent PR guy can turn "the XYZ-5000 sprays customers with burning acid" recall into "XYZ really cares about its customers, and as a lovely fluffy precaution we're fixing all our XYZ-5000s, even though most of them are perfectly super and don't experience moderate thermal variances". Engineering, QA, customer relations, finance - every department doesn't get to communicate with the public (or do anything that's obviously going to end up being public) without someone in PR there to make sure the message is put out right.
Legal departments, by dint of (often broken) corporate org-trees are a notable exception to this. When they see a problem, they fix it the lawyer way, and the rest of the company never knows until after the fact. In olden times of yore stuff like this was trivia between one legal office and another, and only the most nebbish of corporate historian ever know why a product changed its name or wasn't orange coloured any more. So the lawyers behaved as they always did, striking as quickly and as hard as they could, writing letters as outlandishly vitriolic and court pleadings as wildly exaggerated as they felt they could get away with, knowing that things would stay on the downlow and whatever happened only the outcome would matter to anyone.
They didn't consider that, if you sent someone a demand letter, the first thing they'd do is tweet about it to their entire customer base (which turns out to be a big proportion of your customer base too), and post the letter (with all its wild and crazy claims) on the internet, for everyone to point and laugh at. If it's the all-too-common shot across the bows (rather than a serious attempt) you risk looking like a rather unhinged bully.
Like it or not (and the lawyers don't like it, and decorate their broadsides with all kinds of "if you publish this letter we'll sue to for that too" stuff) everything anyone in the corporation does reflects on the whole outfit. The PR folks should be in on the ground floor with anything like this. They don't get to veto every lawsuit or every letter, but they can put a choke-hold on the stupid. Right now Zenimax's PR guy has his head in his hands; I'll bet the first thing he knew about the whole affair was when he read it online, and he'll spend next week fighting fires and soothing angry faces. Notch probably won't change the name, but if he does that's just another news cycle of bad PR for Zenimax.
They're not thinking about this for what we're currently call a "phone". They're looking at very small form factor devices which keep their data in the cloud, are configured by another (arbitrary) device which talks to the same cloud, and which make either sporadic or continual data connections with whatever available networks they find, to keep up to date. Imagine very small devices (wristwatches, eyeglasses, earplugs) with 802.11/UMTS/WiMAX radios (which use a mini-sim to identify themselves to whichever network they encounter). And they're thinking about these things as universal identifiers and payment tokens.
Right now you go running with an iPod. Instead you'll have a iPlug, a pair of little in-ear headphones, but with no cable and nothing strapped to your arm. You set up your music program on a tablet, and it seamlessly syncs. You run further than you'd expected, so the iPlug connects to the network and downloads more music. Miles from home your knee gives out. You touch the iPlug and say "taxi". A taxi comes (sent by Apple to the location the iPlug knew; Apple gets a dollar from the taxi fare, which you pay using the iPlug).
You have a iSim unit in your iWatch. You're thirsty, so you touch the watch and say "coffee shop". The watch face shows an arrow to a nearby one, and the distance, and walks you there. Apple gets a dollar. You buy a drink with the iSIM as a payment token (Apple gets 30 cents) and sit down at a table. The table's surface is an active display; it talks to your iWatch and opens a connection to your account in the iCloud. Your personal news appears, your emails, your documents. You do some work, browse some stuff, and when you're done you stand up and the table blinks off. Things will be as you left them when you next peer with an active display - at home, in the car, on the train, at the office, on the beach.
All of this stuff has been done, in various disconnected ways, already. You can pay for stuff with your phone, in some places. Most Europeans (well, Brits at least) have smart cards in their credit cards. You could hotdesk 10 years ago with a Sunray (kinda). You can unlock doors with a Dallas button token. Having super-cheap super-light totally ubiquitous networking makes the whole thing join up into a compelling, powerful, system.
You'll never be alone again.
My company recently bought a used copier/scanner/printer, which had supposedly been reconditioned and cleaned. It included a "document server" feature, whereby jobs could be scanned to its internal disk (or print jobs could be stored in the printer for later printing). The salesman who sold it to us had helpfully left scans of his current account statement in the document server, together with some placating letters to other customers. After thinking about what uses we'd actually have, I decided just to turn the document server feature off for everyone. I did leave the deferred-jobs part on (as it's useful when someone is printing on weird stock or printing something confidential) - thus ensuring that anything left on the copier (the company is now defunct, the copier presumably resold) is guaranteed to be juicy.
Of those phones which do ring in an inappropriate place, the owners of the great majority have simply forgotten to turn their phone off (they're forgetful, not sociopathic). Movie theatres, concert halls, libraries and other please-keep-quiet places could have short-range radio equipment inside which sent a "this is a quiet zone" signal. You'd program your phone (and it would come programmed by default) that when it was receiving that signal it would go onto the vibrate-only ring preference. When the signal was lost, it would revert to your default. So when you entered, and when you left, there would be no need to remember to set the phone correctly (the nagging ads always remind me to turn my phone off, but very often I forget at the end and leave my phone off for the remainder of the day). Similarly noisy places like train stations and airport concourses could broadcast a "this is a noisy environment", which your phone would typically interpret to mean that it should use a loud, shrill ringtone.
There are people who legitimately (and quite reasonably) should have working cellphones in quiet places - doctors on homecall, standby emergency workers, out-of-hours plumbers, parents who've left their kids with a teenage sitter. Enabling these people to use their phones sensibly while largely preventing accidental annoyances would be a great (and surely hot difficult) idea.
Phones should, incidentally, have an "answer with hold" button. So a doctor in the movies whose phone rang (silently) could take it out, notice that it's the hospital's number, and push "answer with hold". The caller would get a short recorded message saying "this person is aware of your call, and will be with you shortly - please hold" - that way the doctor can take the call, but doesn't have to talk into the phone until they've walked into the theatre lobby, where they can take the phone off hold and talk.
Of those phones which do ring in an inappropriate place, the owners of the great majority have simply forgotten to turn their phone off (they're forgetful, not sociopathic). Movie theatres, concert halls, libraries and other please-keep-quiet places could have short-range radio equipment inside which sent a "this is a quiet zone" signal. You'd program your phone (and it would come programmed by default) that when it was receiving that signal it would go onto the vibrate-only ring preference. When the signal was lost, it would revert to your default. So when you entered, and when you left, there would be no need to remember to set the phone correctly (the nagging ads always remind me to turn my phone off, but very often I forget at the end and leave my phone off for the remainder of the day). Similarly noisy places like train stations and airport concourses could broadcast a "this is a noisy environment", which your phone would typically interpret to mean that it should use a loud, shrill ringtone.
There >are Phones should, incidentally, have an "answer with hold" button. So a doctor in the movies whose phone rang (silently) could take it out, notice that it's the hospital's number, and push "answer with hold". The caller would get a short recorded message saying "this person is aware of your call, and will be with you shortly - please hold" - that way the doctor can take the call, but doesn't have to talk into the phone until they've walked into the theatre lobby, where they can take the phone off hold and talk.
Any system which relies for its safely on a person "being careful" is doomed, as humans are fallible and make mistakes, particularly in high-speed, high-stress environments like financial trading desks.
One way this problem could have been "engineered out" is:
- Define a "trading limit", which is the maxiumum difference between the stock's current price and the price at which a trader may buy or sell. Maybe this is 5% (it depends on the volatility of the stock, and perhaps on the brokerage's trading strategy)
- Brokers can only perform transactions within this range; any attempt to trade outside this range is rejected by the software. In practice most trades are much much closer to the trading limit, but it's nice to have a wider limit than one would normally use, so the brokerage can react swiftly to market events.
- If, in an exceptional circumstance, a broker feels he needs to transact outside that limit, he places a special request (using the software). The request is relayed to several senior staff (probably senior brokers) and if they approve it, the transaction can complete. Optionally they can approve a temporary widening of the trading limit (i.e. for more than one transaction, but still a limited period such as an hour).
- Tune the parameters (trading limit, mechanism for requesting wider limit, duration of it) so that the company retains most of its ability to react to volatility and so that escalations to the senior committee are rare (no more than one a day - more frequently and you risk them automatically rubberstamping without thinking properly about the matter)
This doesn't entirely remove the problem, but it means the damage that can be done is one or two orders of magnitude less than would be possible in a system where the trader has total liberty.In addition to protecting against inadvertent trades, it also protects the brokerage against a trader who is malicious, depressed, drunk, or temporarily insane.
I'm really astonished that something like this isn't done already, and astonished that it's not mandatory.
Actors have a similar solution already. They just need to go to the Anakin Skywalker School of Acting, where actors are trained to drain their voices of even the tiniest trace of nuance, inflection, tremor, or emotion. Soon they're able to speak even the most emotionally charged lines (e.g. "I don't like sand") with the steely monotone of a T-800 terminator with a flat battery.
Anyway, the image in the NEWS.com.au article is USGS aerial photography, and the same redactions are done in the current data drop (as available via NASA's World Wind system) - so this particular censoring happened before the data got to google.
Indeed, there would be no point in censoring the commercial imagery used by google for the reactor in question, as the enemies/terrorists/Bad Guys (tm) could order the imagery themselves, presumably though some front company. So the aussies would need to persuade several vendors of commercial satellite photos, including US, European and Russian providers, to censor their images.
Note that Space Imaging don't (or didn't, at least) have a blanket list of sensitive US properties they won't photograph - the happily supplied the Federation of American Scientits with lovely images of Area 51: http://www.fas.org/irp/overhead/groom.htm
So complaining publically about google is entirely counterproductive; they're just standing on their own stumps ;)
The skoy waz the colir of a teleevishin tewned to ded chennel ...
You're correct. The grandparent post is of Tonopah Test Range, not Groom The square residential block shown is the "mancamp" facility, a mile or two from TTR. The irrigation circles so suspected by the grandparent article are outside the Nellis Range. Tonopah is was the original home of the F117 after it moved from Groom, and continues to be part of the Nellis Range testing complex - those markings on the ground are part of the system of test targets used by USAF pilots training at Nellis. The "bomb craters" shown on the grandparent's site are depressions in the ground caused by underground nuclear testing in the northern Yucca Flats area of the Nevada Test Site. None of this is particularly secret, none of it is terribly near Groom, and none of it is Area 51.
The worst thing about planets is all the boneheads you have to share one with. Just as soon as you've gotten your patch just how you like it, some twit five thousand miles away sets off his A-bomb, releases his homebrewed filovirus, or just dumps his industrial crap in your shared air and water. In a modest sized artificial environment, no-one can dodge the consequences of his actions (and if anyone tries, you can deport them back to the glowing farty shithole the Earth has become).
Some reading from the "planets are for lusers" squad:
* Michael Swanwick's "Vacuum Flowers"
* Marshall T. Savage's "The Millennial Project: Colonizing the Galaxy in Eight Easy Steps"
The bytecode loop and elementary classloader are indeed straightforward (which is why there are so many of them hanging around), and doesn't really get harder between a barely-working JVM and a decent one. Lots of other stuff, however, does:
- A dumb, blocking, non-generational mark-and-sweep garbage collector is fairly straightforward (handling blocking and native methods wrt GC is a complication, if a manageable one). But for a box serving lots of connections on a busy website, you don't really want half second long pauses while the GC sweeps the whole memory. You really need a generational collector, and you really want one that's either non-blocking (yes, that's hard) or resumable. The nice thing is that the GC is fairly self contained (not entirely, as it interworks with synchronisation and the native method interface) and there are lots of university research groups who have done lots of research on GCs (for java and other languages) so it should be possible either to pick up some research collector or farm the work out to some eager masters students.
- Efficient management of native synchronisation resources has an important effect on scalability. Mature JVMs go to great lengths to marshall the number of native synchronisation primitives the JVM instance uses (e.g. with some kind of mutex pool, assigning an OS mutex to a java one only when it is in scope). They can work without this for a while, but it needs done eventually. I see Doug Lea is onboard, and this kind of stuff is Doug's meat-and-drink.
- The verifier is hard to get right. Sun's one is the product of careful design and then of several analyses by third parties. For example, one univerity wrote a verifier from the JVM spec in a formal language (Z or something) and then threw millions of randomly generated program fragments at their one and the Sun one. Where the two differed, the group analysed the program in depth. From this they found dozens of cases where the two verifiers differed materially; most were due to different interpretations of the JVM spec (which, one hopes, resulted in the language of the spec being tightened) but about ten were nontrivial holes in the Sun verifier. Last time I was involved with this (a few years ago) Sun insisted that all Java licencees (even those who had written their own JVM etc. entirely from scratch) run the Sun verifier. Luckily, the verifier is like the GC - it's a subject of ongoing academic research, so there are universities who might be persuaded to do the heavy lifting. And for a trusted enterprise setup you can do without the verifier anyway (it's really only needed for untrusted mobile code like applets or JINI things).
- But the really big task is dynamic compilation. A bytecode-interpreted system isn't credible for any real application. A JIT will do, at the expense of sluggish performance and drastic memory-munching. A real hotspot-like smart, self-monitoring dynamic compiler is really necessary for a quality JVM. I guess the Harmony folks will spend a lot of effort here, as it's a lot of work and its too tightly bound to your JVM internals to either farm out or to allow you to easily take something off the shelf.
Still, I hope I've not sounded too negative. It's all doable (python and mono do most of this stuff between them, neither with a vast team) and the lack of a free or open JVM has been an uncomfortable gap between LAMP and tomcat for too long.Heck, maybe it's just a strategy to get Sun to open Tiger sooner rather than later.
You know, I was just looking at one, thinking "hmm, that looks kinda >compressed<" (particularly when one is used to looking through WorldWind). You've explained it perfectly, thanks.
The images appear to come from two sources. Non-urban US areas are NASA Landsat-7 images (which, as works of the US Federal government) as public domain. Some urban areas (I looked at Mountain View, CA) are USGS aerial photography montages. Again, as works of the US Federal government, these are public domain too (and available at higher resolutions in WorldWind). Google can only claim copyright over something when they've made a non-trivial contribution toward it (republishing isn't enough). The landsat images have been well montaged and registered, I think by Keyhole (that's difficult to do so well, requiring technique and skill, so that's probably copyrightable). As far as I know, the USGS photos are montaged, registered and adjusted by the USGS, so quite what Google think they've contributed to that is unclear.
There's the 1979 Moon Treaty - see wikipedia.
Taiwan
I had a similar experience with a rental VHS copy of David Cronenberg's "Videodrome". The rental copy (conspiring with a nasty oxide buildup on the cheapo player's play head) began to degrade about half way through, getting grainier and noiser as it went on. By the end it was all snow. Given the subject of the movie, and the preponderance of "distressed" video deliberately present in the original, I was convinced that this way entirely intentional. For _years_ I'd tell people what a clever, original idea this was, having a movie about video messing with you that itself became messier and messier until it vanished entirely. It wasn't until I rented it on video that I discovered the truth. And dammit, I claim my version was _better_ :)
Indeed, it really does require that second viewing. But once you've truly figured out what's going on, and the forward-backward conceit, the third viewing is downright dull. With the tension and ambiguity resolved, Memento turns into a movie with negligible plot and incredibly flat characters. I loved it the first time though, but it has no long term watchability.
Fight Club, on the other hand, is confusing and clever in the same way Memento is, but has far more staying power; there are so many little clues and corners and brilliant lines that it's still entertaining and fresh after a dozen watchings.
Haven't they had the audio part of this (figuring out where gunshots come from) in Redwood City, CA, for years? I believe they do (or did), but that it went bonkers every Cinco de Mayo.
I think it's likely AOL would like to move to a Firefox client, as there are several real business advantages for them, including
The fly in the ointment for them is website compatibility. Sure, most sites do indeed work fine, but there's a sufficiently large number that don't to make AOL switching untenable. A number of the folks I've successfully switched to firefox have migrated back, particularly because either their bank, airline, or corporate portal have been IE only.
Now, AOL has a full list of the sites their customers visit, and can easily compile a list of the major ones that need IE. They can build this list into an integrated firefox-IE browser, so that it switches to IE for those "legacy mode" sites seemlessly. That may well be what this netscape is - a test version of a "smart-switching" AOL client.
If they wanted to (although I can't see as much business case for them to want to) AOL could then put pressure on those sites that don't work with firefox to fix their issues. THey can threaten to start popping up little windows saying "legacy mode support", "backward-compatibility mode", or "old-style technology mode", a mark of Cain the site in question would rather avoid.
But most of all it's an option. In business, an option is an advantage even if you don't take it - in this case it's a great stick with which to beat Microsoft in future negociations. So it's a smart move to make, and a scary (for MS) technology for them to have - it's what MS fears the most, a smooth migration path away from MS.
Wikis are rotten for threaded conversations - stuff gets overwritten, moved around, refactored, deleted, and it can be horrible to follow a thread (essentially everyone has to follow a layout which indicated the thread structure). This is a job for a message board or mailing list - to make this work properly with the wiki, you need single-signon and workable links between the board and the wiki (plain http links are okay, but smarter linking would be better). Ideally the board will support the wiki syntax, or will support embedding wiki "pages" into posts.
Also, it's hard to automatically syndicate or publish a wiki, either via RSS/ATOM or a mailing list. MediaWiki has a teeny bit of syndication support, but not for ordinary content pages. This issue is when to push a set of changes
Integration with your corporate email system, bug/issue-track system (or CRM system), maybe instant messaging system, or maybe VCS system would also be a great thing. This integration is really the "thesis" of Lotus Notes - that collaboration takes places in many forms, and that rather than force users into one paradigm it's better to make all the modes work smoothly with one another; it's really a damn shame Notes hasn't lived up to the promise this integration has.