Wellll....what you're describing is an attempt at knowledgable and responsible
use. Some of that knowledge, which gives
you understanding of how careful you must be, as you have described,
is gained in
the very type of clinical trials required by the FDA approval process.
Unfortunately, where clinical trials are perceived to be biased and
regulation perceived to be unnecessarily draconian (criminalised, for example),
the only way users of those substances find out the real level of care
that needs to be exercised is through trial and error on human subjects, and the results
of their "experiments" are only be conveyed through rumour and anecdote--
the legendary bad trips you hear about, people
winding up institutionalised or dead, through uh, not exercising due caution.
Even in the
unregulated herbal preparations, the quantity of the active
ingredient can vary wildly from batch to batch, which can make responsible
use more difficult. Regulation would ensure more consistency
from batch to batch, along with published guidelines on responsible use
(no different than the dosage recommendations on a box of aspirin!)
which can prevent others from unknowingly using the herbal preparation
in a way that would harm themselves and others. So, in a lot of ways
we actually agree on the fundamental issue.
I used to pop a couple Sudafed
myself, once or twice a semester, to help study--a cup of mah huang tea to
clear your head: that sounds even more reasonable! But if you've ever had to be
the responsible family member dealing with
a parent or sibling who has abused ephedrine, alcohol and other natural,
organic and/or legal
psychtropics irresponsibly
over a long period of time, you might feel differently about the importance of
the importance of testing their effects (particularly the long-term effects
of prolonged use!) and regulating their use.
Someone who has become inured to rather massive daily doses
of a tincture of mah huang is doing physical damage to their heart, has developed
a physical addiction to the stuff, and does a lot of social and emotional
damage to the people around them. And they can become violent. The constant sleep deprivation
alone would be enough to induce serious psychosis. And yet, because it's "natural and
organic" they think they can take as much of it as their addiction demands. There's
no warning on the label!
I think you'll agree that the heavy-handedness of the FDA's approach to
some of these substances only polarises and politicises the issue (and
unfortunately they're particularly fond of slippery-slope arguments and other logical fallacies in their
debate, which doesn't serve to convince anybody!)--
but at least the public debate gets the idea out to people that they do
need to be extremely cautious. If the FDA rather conducted a campaign to distribute credible and
balanced information on the basis of unbiased clinical trials regarding some of these
substances, they might be
far more effective in pursuading people to exercise an appropriate
level of caution, and thus serve the public interest more effectively.
Well I used to update our /etc/hosts (in Unix, we don't use the suffix -- you
must have been on one of them VMS machines, calling it HOSTS.TXT!)
every friday without fail--
but then, campus networking would do the (long, slow) download from sri.nic.arpa for
the benefit for the rest of the sysadmins, plus you could get just a patch and
apply the diffs -- so it wasn't that big a deal to get
it over the network, no hours of babysitting an FTP link back to the mothership
SRI. Sort of like the way DNS actually works now -- like a
phone tree.
I figured they got the idea of how to set up the DNS distributed hierarchical
database bits by studying the pattern of how
people actually distributed their hosts files -- and wouldn't it be nice
if they'd only have to distribute the changes: just like sending out
weekly patches. Plus
ca change, plus ca change pas.
When we got ahold of the first alpha and beta versions of BIND
in the mid-80's,
downloading the hosts table was still preferable because there were
just too many bugs in BIND at that stage. It's kind of annoying
that so little stuff is set up to fall back to the hosts tables
properly anymore.
Thanks, Eric. I had to deal with someone close to me who was essentially
addicted to ephedrine through daily use of "Mah Huang" aka ephedra sinica,
a natural herbal supplement, the active ingredient of which is ephedrine --
which is no less harmful than crank. It can be just as deadly, too -- an overdose
can be fatal. Way, Way bad!
pseudephedrine is the manufactured ingredient, the main ingredient in Sudafed,
a leading decongestant. The same people that wouldn't take a handful of Sudafed
will go ahead and take the equivalent dose of mah huang, because it's natural
and organic. So is deadly nightshade. Not a great idea.
While it would be a shame if every herbal tea company were regulated into oblivion,
its also clear that some "natural organics" can be quite dangerous (tobacco, psilocybin
mushrooms, peyote buttons...)-- not to mention
all kinds of unnatural inorganic treatments people try.
Prior to the founding of the FDA there were some truly dangerous quack treatments --
electrical shocks to the nads for STD's for example. Unscientific, dangerous and quite
scary stuff!
Although not mentioned in the article, licensing costs per unit do play an
important role in many companies' decision. I know of two companies here
in NZ who were offered substantial discounts on the OEM licensing of WINCE
on their devices only after considering Linux (for access to its TCP/IP stack,
and other comms facilities). If you're planning on selling like 100 thousand
to a million units, the difference between 10 bucks NZ per unit licensing fee and
3 bucks NZ per licensing fee makes a huge difference.
Of course, zero dollars per
unit is even better, and access to RTOS source for zero dollars is even better,
but it turns out that it's perceived by companies making these devices (who
typically often have more EE's who happen to know how to program, than, say, linux
kernel and device driver experts, or experts in some other RTOS) that it's
better to take a small hit (3 bucks NZ per unit) on the proprietary embedded OS per unit than to have
to develop the expertise in-house that they would need to in order to really
take best advantage of an open source RTOS. It's when they're looking at having
to take the big hit (10-15 bucks NZ per unit) that Open Source becomes more attractive,
but that's precisely the point at which M$ is willing to lower their price per unit on WINCE.
Were that it weren't the case. What we really need is a big player
who is willing to actively offer to these companies licenced support on an embedded linux
at a lower cost than what M$ can do. By "actively" I mean having people on staff who
will phone up the engineering managers of these companies and make a deal with
them to supply kernel and device driver support, and to train their staff
at a lower cost per unit than M$ will charge for WINCE. Then we'll start to see
greater growth in the embedded linux market.
It's the steep learning curve for Open Source RTOS and
the perception of lack of ongoing support that makes these companies willing to
pay for proprietary embedded OS's, unfortunately.
Time and time again, we've seen M$ offer special deals to
large organisations that "decide" to use OSS by decree --
governments, universities, companies. (Could this be the
motivation for issuing these decrees on the basis of price
alone in the first place?)
We've also
seen M$ or their proxies (e.g. SCO) take steps to punish organisations that stick with
their OSS decisions.
The threat implicit in the "ISC"'s choice
(and shame on them for appropriating the good name of the
real ISC) is that
the first hint of any problem with OSS, and they'll
raise a ruckus in the media and try to discredit the public
officials who did not choose " the best " software for the
job, but made an "ideological" choice.
The only argument that can stand up to this onslaught is that
data formats need to be open, so that the owners of the data
can maintain their ownership. This argument has been made
brilliantly in other contributions to this discussion.
We might add to that: the owners of the data
need to be able to see the source code of the programmes and
operating systems (particularly the network components) which
manipulate and communicate those data in
order to avoid theft, misuse and misappropriation of those data.
Australia and New Zealand have exceptionally strong
privacy laws -- and these laws are enforced. People,
government bodies, and even large corporations with deep pockets
take these laws very seriously, even though Echelon seems
to be exempt ( NB: This is a different discussion.).
One way that South Australia could help itself stick by its
decision to use OSS in the face of these lobbyists would be to refer to
its own privacy legislation as the prime driver for OSS, rather
than price alone.
When I was a newbie Unix Sysadmin in the mid-eighties, it was at a Very Large University
that had been given an IBM 3090 "supercomputer" (while the administration, whose
salaries were paid for by IBM Corp, purchased a second for full price ,
at a time when typical academic discounts from Sun and SGI were up around 50%). Well,
there were a number of IBM employees "advising" University IT services full-time
with offices on campus . They were there to squash any and all use of non-IBM
gear, they were.
IBM didn't really have a Unix offering at that time, and the
faculty were just clamoring for Unix mini's -- Suns, SGIs, DEC VAXen running
BSD 4.2/4.3, Apollos, HPs -- even PC's running XENIX. The faculty found it was more
beneficial to their research projects
to buy a smaller computer but have it dedicated to the project, than to have to buy
time on the University supercomputer. For one thing, they'd have the hardware for as
long as it lasted, and have, well, root access. And they could hire monkeys like me
for peanuts to keep them running -- on the network!
Well, my installing BSD on VAXen and keeping a network of Suns and SGIs running
on the network made me none too popular with the Brainwashed-By-Big-Blue Brigade--
much as my putting cygwin on Windows boxes and occasionally whiping Windows altogether
with a nice Linux install makes me none too popular with the MSCE's that
infest corporate IT department these days.
But in academics, as well as in business, it's the Golden Rule: the ones with the Gold
make the Rules. By bringing in research grants, the faculty, who wanted
unix boxes, were making the rules. Also, since much of the money was coming in from DARPA and Friends, who
all championed BSD (having funded its development) we had the funding agencies to refer to as well.
But the B-B-B-B Brigade would continually
try to sell us time on the 3090 -- and we would be, like "get your eyeballs
off of my stack, jack!"
I recall numerous
acrimonious meetings with the BBBBB where they would point to this wonderful "gift"
of the 3090 as obligating us to use it -- at which point we would counter
with "Well, if it was running UNIX, we'd consider it..." They'd come up with their
FUD to the tune of "Well, IBM is working on Unix versions..." (referring
to AIX which was vaporware at that stage, and a BSD RISC machine that unfortunately never got off the ground).
But BOOM! We'd
hit them with "Why not just install UTS on the 3090?"
Oh! The dirty looks we'd get for that one! Talk about hitting a raw nerve!
But now, IBM is our new best friend. The FUD Fighters and Champions of AIX and Linux.
It is way beyond ironic. It is so deeply satisfying!
Now IBM is famous for its interdepartmental rivalries. I do sometimes
wonder if our little blows against the
empire at that stage had anything to do with the ultimate rise
of the groups, internal to IBM, that were behind the development of AIX.
The truly ironic thing, though, is that the technical sophistication
and security features of the PPC chipset and OS/400 systems architecture
are really starting to impress me as being quite a bit better than what
either linux or unix on any hardware platform ever had to offer. *nix is just starting
to get serious database-tuned journaling file systems, stable security
implemented, VM's (or LPARs) to your heart's content, and use of an instruction set that can directly
manipulate tables of 64-bit hash keys (on the PPC anyway). The AS/400 has had these things
for a looooong time. So...maybe we were wrong back in the 80's, and IBM had it right
the first time.
This is great, great news. I drove through Yellowstone and half of Wyoming on a tape of
Twin House. One CD I still haven't been able to find is Lambert, Hendricks and Ross --
a recording they did that had "Cloudburst","Centerpiece" and "Twisted"
(amongst others).
My favorite Coltrane has always been Giant Steps , which shows up in the bargain bins
all the time, as does a CD that has both Sonny Rollins albums Tenor Madness and Saxophone
Collossus .
There's a delightful duo of Earl Hines and Stephane Grapelli out as well, a single session,
their first (and last) meeting, where they do just an incredible version of "Moonlight in Vermont."
Besides being completely unprofessional, is totally and completely
morally wrong to initiate and maintain sexual relationships with co-workers
and clients. And we can add subordinates, contractors, direct supervisors, professional colleagues,
students (undergraduate, graduate and postdoctoral), faculty and administration to that
list. Even where the personal relationship pre-dates the professional relationship,
there are serious moral, social and professional issues -- issues that
simply don't exist when the two spheres are kept separate in fact as well as
in the shallow "maintaining a professional image" you describe.
What you describe is more like living
a double life. You're the same person when
you are home versus when you are at work. If you're not operating from the same
set of values and principles in both spheres, you lack personal integrity,
and I know from experience to stay well away from people like that.
Now I've heard certain women's refusal to put out for the boss ascribed to the
woman's "immaturity", which is just pathetic. A guy has no
business trying it on with her in the first place, but then tries to reposition his
own lack of personal integrity as "maturity". It's not "mature" to expect women
engineers, mathematicians, programmers, scientists, clerk-typists -- what ever-- to put out.
It is morally
WRONG . If the guy that much "in love" with her, he can bloody well
recuse himself -- change jobs.
Work somewhere else. And if he's not that much in love, he can bloody well keep it in his pants.
It's not "immature" for a woman to
know the difference between right and wrong.
A female who does is a "slut", and
a female who does not is "immature." Given that you have the choice between being
denigrated no matter what you actually do , the only rational choice is to do
what you know to be morally right regardless.
Ethically, the situation is very similar to, say, a police officer amongst a group of
corrupt police officers. If he does not take a bribe, the other police officers will
become afraid that they will be exposed themselves in their corruption, and they will do whatever
it takes to get rid of the clean cop. If he "goes along to get along" he will not be
able to respect himself in the long run, and he may even eventually get caught out
engaging in the very corruption that he so reluctantly went along with in the first place.
Either way, he's damned in the eyes of the world. His only way out is to do the right
thing regardless of the consequences. At least he will be able to look himself
in the mirror every morning. He certainly won't have to write elaborate memoirs and
novels to justify his behaviour.
Now it's a real shame that Ms. Ullman just doesn't know the difference between right and wrong. A
real shame. I feel sorry for her, I really do. I feel doubly sorry for her that her moral relativism
is celebrated by Salon and the NYT, because it will just take her that much longer to figure it out,
and she'll take others down with her into her little cesspit.
If she did know the difference between right and wrong, and
had kept up with modern code instrumentation and debugging tools, she might still be a programmer.
While it's unclear whether she left the field primarily because she'd been screwing around,
or because she wasn't keeping up with her field, it was probably a combination of the two.
We know both cases to be true.
Since when is it inhernetly unprofessional to maintain personal relationships with co-workers/clients?
Ever since Potiphar's wife came on to Joseph, and Joseph had to
say "thanks, but no thanks" and suffer the consequencs. It's not OK.
You don't screw the crew. End of story. It's not good programming,
and it's simply not professional.
A memory leak is a failure to deallocate memory causing the program to consume ever more system resources.
Which causes transient failures, typically at different locations in the code
every time. Fact. You obviously have never had to work with code that has
a memory leak. And a buffer overflow is a type of memory allocation
error.
a few abstract concepts: how about FACTS
on
The Bug by Ellen Ullman
·
· Score: 2, Informative
You said:
lemme introduce you to a few abstract concepts
like fiction or artistic license.I don't believe the narrator of "Close to the Machine" is Ms. Ullman herself.
in response to my comment that
in "Closer to the Machine" she gets intimate with clients and co-workers during the project even
Mr. Jpeg: did you read it? Closer to the Machine is a MEMOIR.
From the spamazon Editorial Review of Closer to the Machine by Cliff Barney:
Author Ellen Ullman, an independent computer programmer, holds little back in recounting her experiences. She discusses her business career, her approach to software and her sexual adventures, all with the same frank detachment.
Read it and weep. What I find so disturbing is the non-technical
community's (read: Salon, Book Editors) lack of censure for her
non-professional approach.
And, The Bug--oh!! A bug that only happens sometimes at different
places in the code? Christ on a bicycle, hasn't she ever fixed a freakin'
memory leak before? Corruption she's clearly familiar with, but
this kind has a blindingly obvious Simple solution. Instrument the code with Purify or
Insure++, or Electric Fence or at least check where and how memory is being allocated and
deallocated. This isn't rocket science, you know. Oh well, guess that's the difference between her
"20 years of programming" and my 25.
Sure The Bug is fiction, but
it's fiction based on a truly lame approach to debugging.
Yah! And I can see Scott Adams doing the writing for it.
There was a British series called "Attachments" that
actually had some decent programmer content/activity,
though it was dominated by dotcom management pratfalls
and consequences
that we've all seen in real life by now, so why make yourself
sick watching it on TV.
What's more interesting is the "junkyard wars"
format, with
Robot Wars
and Robotica. And yet you don't get very good
representation of the interesting part -- they're
presented like Pro Wrestling.
How do you illustrate the process of problem solving in a
visually compelling way? Better yet, how do you engage
the viewer intellectually in the process? There's the
dramatic twist, the quirky character, the suspense --
but the most engaging it gets, really, is in the whodunit or
the spy "thriller". And these are so formulaic, predictable
and worn-out by now, that there's just no fun in them.
Science and Techno documentaries are by far the worst--
their Breathless Admiration of The
Great Man Of Science and His Great Discovery, or
This Wonderful New Technology And How It Will Change Our
Lives. How utterly boring.
Why don't baptists hack standing up?
on
The Buttocks Have It
·
· Score: 0, Flamebait
While it's preferable when females write intelligent
things about the scene (vs. writing stupid
things about the scene ala aimee deep), and are cast as intelligent
females in fictional accounts of hacking (as in Digital
Fortress ), or even as interesting characters in computer games (Lara Croft)
"The Bug" is still a female writing about
computers, rather than writing software , developing algorithms ,
modding hardware etc.
OTOH, any progress is good, and since progress in the area
of "the image of female geeks" requires a substantial change in the culture ,
perhaps the best place to promote this change is through
cultural means.
The terrific thing about The Bug
is that the author has written code, so she's writing
from experience so we don't get the kind of nonsense we
saw in, e.g. "Swordfish." Swordfish was just crap.
I mean, come on, why all the blood
and guts surrounding gaining physical access? If they had
to gain physical access to the servers, they weren't such
great hackers. Doh! Plus, much as I like Halle Berry
the thing
her character did was social engineering--she had to bring
in the male gun techie to do the real work. eeeeeyuck!
Again, if her social engineering skills were that great, why
didn't she just apply it to the problem at hand, rather than the
complex and messy techniques the Travolta character came up with.
This was the only regard in which Swordfish was realistic: the gal
had the by far better skills to solve the problem simply and
quickly, yet the solution that got implemented was some big messy
over-complicated plan developed by the guy. Typical !
By contrast, I just loved Angelina Jolie's character in
"Hackers," errors of fact and ludicrous storyline notwithstanding.
She played a great character in Tomb Raider as well--too bad about the muddled plot.
And who could forget Carrie Anne Moss' SSH-1 'spoit in Reloaded?
It's when Ullman is brought in as the technical consultant on the
Hollywood production of The Bug, and perhaps even Digital Fortress,
and we consequently see the first
believable and intelligent movies on the topic, that
we'll finally see a triumph of substance over style. And I
hope they get Angelina Jolie or Carrie Ann Moss to play the lead!
On one project, we used PostGreSQL's GIS extensions, PostGIS under SuSE for the prototype,
as the prior GIS DP methodology was to do all the GIS processing by hand
on a windows desktop--which read and wrote.shp files. Gross! After developing a prototype
DP stream in PostGIS, which is OGC compliant,
it was fairly simple to migrate the DP methods (all SQL with OGC-compliant GIS data formats
and stored procedures) to DB2 Spatial for the bulk processing, which could handle even
larger data volumes, and much, much faster. By about an order of magnitude.
Hours instead of days. Is it an "open source failure" to prototype a process using
an open source tool, then migrate it to a proprietary product that's actually better?
Both still ran under SuSE.
It demonstrated the utility of doing the GIS processing required with a spatial
database rather than a silly little pointy-clicky windows app. Without the OGC standard
that both PostGIS and DB2 Spatial adhered to,
however, it would have been a real nightmare.
LandSat 7 is simply not as capable of a sensor as some of the others out there. Shutting it down without shutting down better sensors is wasterful and strategically pointless.
I'm not sure about that. For one thing, it's more plausible for an old satellite to "malfunction" than a new one.
The other thing you need to consider is timing and coverage. Just because satellite A is better than B
doesn't mean that it will be where you need the data at a particular time. No matter how you slice it, the data
volume and coverage from A+B > the volume and coverage from A,
unless the data from B is literally worse than useless.
Your "simple inductive logic" reminds me of an old joke:
A mathematician, a physicist and an engineer...
I know. That's why I identified formulating projections on the basis of past known events as inductive logic,
rather than deductive logic. We're calculating probability density functions here, not proving that something
is definitely so or not so.
By the way, can you give any substaniated examples of a satellite being shut down permanently when it was putting out data of military significance?
Yup! SeaSAT
failed after 116 (or 106, or 99, depending on which source you believe) days of operation.
The person doing the analysis showed me the pictures.
I was just an undergraduate at the time. The high-res
SAR data stopped coming through well before the low-res -- odd, considering the
failure of the satellite was attributed to a massive power failure.
The data were militarily significant for the better coverage of ocean floor topography
than was practically feasible to gather with sonar -- again, coverage is key
here, not resolution. Sonar gives you better resolution, satellite geoid and topography
gives you better coverage, particularly in areas where it's difficult to conduct
bathymetric surveys--around Novaya Zemlaya for example.
Subsurface topography is the widely acknowledged military
significance of these data. The person doing the analysis
was specifically asked to decimate these data prior to publication--
remove the spikes. Sub holes, strategic canyons and particularly
"anthropogenic time-dependent spikes in the sea
surface topography". Sub wakes. He did it. I would have, too.
The later GeoSAT satellite data were held by the US Navy and not declassified until after the Cold War.
This is the perfect conspiracy theory: it's almost entirely plausible, almost impossible to refute, and we want to believe it!
Reasonable suspicion based on past known behaviour does not a "conspiracy theory" make.
Every time a remote sensing satellite goes black, it's worth wondering of what tactical or strategic
value was the data. And to do this well, you need to know what image processing and
multisensor fusion algorithms are currently being used, by both your own nation, and your
nation's enemies, as well as what other data they have available. It's not just the raw data, bucko.
On the other hand, I can get a pretty good aerial view of Downtown Baghdad any time I want it.
Yes, but what about Bankok and all of Brazil? What about March 2000 vs June 2003, i.e.
What is your coverage like over time? Ever wonder what's going on just out of range
of a single image? What went on the month before or the day after? What the area looked
like in a mulispectral, SAR or IR images? What if your multisensor fusion
algorithm is ten times more accurate when you add
low-res multispectral to your high-res optical? What if it becomes ten times
more useful when you have three images to compare over time, in the same area,
versus just one? What if your algorithm has far greater strategic value if part of the data are
believed by your opponent to be simply unavailable due to ostensible satellite malfunction?
What if half of your own functioning satellites were taken down in a war? Wouldn't you
be glad to be still getting the data from the ostensibly malfunctioning ones?
These are actual questions pondered in actual meetings. I have been presented
with them in a technical setting, in the development of actual image processing
applications. It's hardly a "conspiracy theory" to say that these questions are asked.
20-20 tunnel vision is of no use when there's a truck full of explosives coming at you from left field.
You need your peripheral vision for that. And it's the missile coming right at you that's the
hardest to measure the velocity of. So the more points of view you have, and the more measurements over
time you can make, the better off you are, from a defense standpoint. As an American
Citizen, I happen to like my country being well-defended, so I don't think
it's necessarily a bad thing if LandSat 7 went black for some reason other than a straight malfunction.
But it does make me wonder.
Actually, I worked on several image processing projects for the military, and we certainly did use LandSat data. And SPOT data (optical band) and SAR data (K band and X band mostly) as well as IR data.
The advantage of LandSat data is the broad spectrum of data returned, not the resolution. As a consequence, LandSat data alone has little tactical use, but it has tremendous strategic value -- particularly when geolocated and registered with data in other bands, and in conjunction with other data. In one project I did for the Comprehensive Test Ban Treaty Verification Organisation in Geneva, the challenge was to develop criteria for distinguishing mining sites from non-mining sites using satellite imagery. What does this have to do with A-tests? you may wonder. An underground explosion could be part of a mining or roadworks operation, or it could be a nuke test.
You've got the location of the explosion easily enough from the seismics, and it's easy enough to distinguish from an earthquake by its distinctive P/S wave ratio (explosions have almost no shear wave component, it's all compressional). Now how can you tell if its an ongoing mining operation without actually visiting the site? First you geolocate and register your LandSat, SAR, AVHRR and SPOT data to each other in the region of interest. Throw in some vector road maps and topography while you're at it. Imagery from different days, months, years, decades in the same area is also quite useful. Now you can either sit down an analyst in front of the data, or you can develop algorithms for identifying mining sites from various combinations of imagery. When you're done, let me know. LandSat data is tuned for collecting land-use information. Tree cover, grasslands vs. exposed rock for example. Clearings in the jungle that weren't there before. Desert areas that suddenly change to vast warehouse complexes well away from the largest roads and typical commerical trucking routes. Get the picture?
It is of tremendous strategic value to unobtrusively monitor land use over time, over large areas, for all sorts of military applications. Other data are better for tactical applications in a silly little game of soldiers, true--but you're not going to even want that level of resolution and targeting for determining new developments. The world is a big place. Where do you look first, and what kinds of anomalies do you look for? What anomalies are potentially of strategic significance? Quick, give the answer without LandSat data. Not as easy now, is it?
And as for calling it a "conspiracy theory" -- it's rather well known that there exist American satellites that have been said to have malfunctioned that have certainly not, because the data being returned was found to have military, strategic or other significance. The LandSat 7 "malfunction" could well be another instance. No conspiracy there. Satellites go black for different reasons. Malfunction is just one of them.
Look at it this way. I leave five dollars on my desk and it disappears. The thief is caught on camera and given a warning. A week later I leave five dollars on my desk again, and, again it disappears -- but this time the thief is not caught on camera. Is it "a conspiracy theory" to say, well, this guy was caught stealing once, and he was in the area at the time, so of course we're going to question him. Does calling this reasonable suspicion based on past behaviour a "conspiracy theory" wash? No. It's just simple inductive logic. Get over it.
You have obviously never seen Landsat data before. It is of little or no military value. There is no conspiracy here. Satellites break. Get over it.
Actually, I worked on several image processing projects for the military, and we certainly
did use LandSat data. And SPOT data (optical band) and SAR data (K band and X band mostly)
as well as IR data.
The advantage of LandSat data is the broad spectrum of data returned, not the
resolution. As a consequence,
LandSat data alone has little tactical use, but it has tremendous strategic value --
particularly when geolocated and registered with data in other bands, and in conjunction with other
data. In one project I did for the
Comprehensive Test Ban Treaty Verification Organisation in Geneva, the challenge was to develop criteria
for distinguishing mining sites from non-mining sites using satellite imagery. What does this
have to do with A-tests? you may wonder. An underground explosion could be part of a mining
or roadworks operation, or it could be a nuke test.
You've got the location of the explosion easily
enough from the seismics, and it's easy enough to distinguish from an earthquake by
its distinctive P/S wave ratio (explosions have almost no shear wave component, it's
all compressional). Now how can you tell if its an ongoing mining operation without actually
visiting the site? First you geolocate and register your LandSat, SAR, AVHRR and SPOT data to each other
in the region of interest. Throw in some vector road maps and topography while you're at it.
Imagery from different days, months, years, decades in the same area is also quite useful.
Now you can either sit down an analyst in front of the data, or you can develop algorithms for
identifying mining sites from various combinations of imagery. When you're done, let me know.
LandSat data is tuned for collecting
land-use information. Tree cover, grasslands vs. exposed rock for example. Clearings in the
jungle that weren't there before. Desert areas that suddenly change to vast
warehouse complexes well
away from the largest roads and typical commerical trucking routes. Get the picture?
It is of tremendous strategic value to unobtrusively monitor land use over time,
over large areas, for
all sorts of military applications. Other data are better for tactical applications
in a silly little game of soldiers, true--but you're not going to even want that
level of resolution and targeting for determining new developments. The world is a big
place. Where do you look first, and what kinds of anomalies do you look for? What anomalies
are potentially of strategic significance? Quick, give the answer without LandSat
data. Not as easy now, is it?
And as for calling it a "conspiracy theory" -- it's rather
well known that there exist
American satellites that have been said to have malfunctioned that have
certainly not, because the data being returned was found to have
military, strategic or other significance. The LandSat 7 "malfunction"
could well be another instance. No conspiracy there. Satellites go
black for different reasons. Malfunction is just one of them.
Look at it this way. I leave five
dollars on my desk and it disappears. The thief is caught on camera
and given a warning. A week later I leave five dollars on my desk
again, and, again it disappears -- but this time the thief is not
caught on camera. Is it "a conspiracy theory" to say, well, this
guy was caught stealing once, and he was in the area at the time,
so of course we're going to question him. Does calling this
reasonable suspicion based on past behaviour a "conspiracy theory"
wash? No. It's just simple inductive logic.
Get over it.
During the Reagan administration,
when a high-resolution statellite instrument to measure the
earth's geoid and topography
was suddenly found to be extremely useful in locating
submerged submarines (by way of their wakes)
it, too, suddenly "went dead." I knew the guy at Lamont-Doherty Geophysical Lab
who discovered how to recover the submarine wakes from
these data. Funny how only the high-res instrument (the one that
could detect submarine wakes) suddenly "went dead." The low-res instrument
continued to return data. It was an open secret in the geophysical
community that the high-res instrument didn't actually have a malfunction.
Funny how the US won the cold war with a few years after that, too. Hrmmm.
It was also the Reagan administration that privatised LandSat -- after
spending billions of taxpayer's dollars to develop and deploy the
LandSat satellites and do additional TM work from the space shuttle,
suddenly all of the imagery was owned by a private company. And
government-sponsored projects, instead of paying like $350.00 per
scene, suddenly had to spend $3500.00 per scene. Double that to
account for "University Overhead." What I want to know is, why,
after paying for the development and deployment of this technology,
do we (as taxpayers) then have to pay for it again when
a project is formed to analyse these data? Didn't seem right at
the time. Still doesn't seem right.
But I honestly doubt the LandSat 7 TM instrument actually went dead. It was
probably found to be returning data of military significance, and
why bother with the political rigamarole with the scientific research
community, not to mention the delay involved with classifying data --
when you can just claim the thing "went dead"? After all, who is
going to make the trip to the thing itself to verify the claim that
it "went dead"?
Yah. SuSE did cut back its US ops a few years back. Too bad for the US.
Here in NZ, we have neither a RH or SuSE office, so "whether-or-not-they-have-a-local-office"
just doesn't make a difference in the "RH vs SuSE" debate.
One thing that does make a
difference (to us) is the overall management of the company itself, which will affect its
survivability and business reputation. RH was involved in a pump-and-dump stock
scam a few years back, as was VA. Not so for SuSE -- they cut back their personnel
expenses when it was a good idea to do so -- just before the dot-com bubble done dot-bombed.
Don't bother with going above his head or breaking whatever you've got going now. Rather:
Get the go-ahead from your "Glen or Glenda" Manager (in writing) to develop
the counterproposal to whatever the conslutant has to offer.
If (when) he/she/it still says "no", get this in writing too, along with the justification.
Now. Take each criticism, and take it to heart on the next version of the SW development proposal.
Do it on your own time, AT HOME . Your boss's "no" to your proposal
means that this development
is already outside the scope of your current job. In writing and dated, it's legally, provably,
factually and equitably true. Guess what stuff you do on your own equipment and in your own time, and
outside the scope of your current employment is? YOUR IP . You own it. It is yours.
...
Profit!!
If you feel you need extra reassurance on the IP issue, and you really think your product is going
to make a bundle someday, have your "Glen or Glenda" initial the proposal and the rejection letter.
Mail the originals to
yourself, registered mail. Do not open it when it arrives. Keep an extra copy for your records.
If your product makes a bundle,
the University WILL try to take credit, and the profits. Your first response will be to
let the university know what it is you have in your own defense. If they're smart, this will shut them up.
But universities have this arrogance that typically misinforms their legal judgement on IP matters.
So, be prepared to drop
a couple thou on a lawyer to ram your registered letter into their hindquarters, rolled up into a tube.
(don't forget the hamsters!)
The cooler and more profitable your product, and the more wrong their rejection of and subsequent claim to your product,
the more joy you will have in watching them get felched^h^h^h^h^h^h^h^h^h^h^hlose in court.
It's like bowling for dollars! Set 'em up--then Knock 'em down!
I mean, if this manager had any skills, she'd get both you in-house and
the consultant working on the solution "to see a demo", and saw what worked
best, without making any concrete decisions or promises until it was
absolutely necessary to make a decision. In the interests of
(cynical spin on the positive approach here) "brainstorming" she'd flatter
both of your sets of ideas in meeting after meeting, getting you to give
away your best ideas in the course of "requirements capture" while the
conslutant takes them, incorporates them into its own products, lands
the fat contract, and gives her a fat kickback and/or perquisites (read: boozy lunches
at the very least).
I mean, we should all be so lucky as to have a manager as honest and
forthright and decisive as yours.
We switched from RedHat to SuSE
several years ago.
Our reasons for making the transition were:
SuSE's stable enterprise/server editions are far less expensive than RedHat's
DB2 UDB and Oracle are both Certified for SuSE enterprise server editions
More specialised sub-distros available if you don't feel like twiddling
and paring down the full distro yourself.
I supported RH from 1997-1999 (IRIX, SunOS, Solaris, BSD 4.2 and 4.3 before that)
My opinion is that the support database for SuSE is better than RH,
and that SuSE's support is much, much better -- and not nearly as often required --
compared to SGI's or Sun Microsystems.
When we made the transition from RH to SuSE, SuSE was streets ahead of RH in security.
While not entirely up-to-date,
Marc Heuse's
article is a succinct and readable yet technically comprehensive introduction.
Areas in which RH and SuSE are roughly equal are:
While RH is the market leader in the US, SuSE is the market leader in the EU.
So going with the Open Source market leader because that's where the best support
and latest developments are going to come from doesn't give you an answer.
While Oracle is doing a lot of work directly with RH, IBM is doing a lot
of work directly with SuSE. So going with the distro that has support from
a large and highly skilled corporate because that's where the best support
and latest developments are going to come from -- also doesn't give you an answer.
Both use RPM, so if you're used to doing RPM from the command line,
there is simply no change. It's very rare that I run across an RPM or a
source package built for RedHat that has even minor glitches on SuSE.
As we're primarily an AS/400 development shop, with Linux just providing
part of the infrastructure, it's been fortuitous that our choice, SuSE,
has turned out to be the most stable distro for the AS/400 and PPC
platforms.
We dealt with no salesperson in either case. Just bought the disks
and support packages we felt we needed, and based our judgement entirely
on what versions of what were already available on the latest
release. Possibly
because the RH and SuSE distro cycles were out-of-synch with each other,
the latest SuSE had the more recent patch levels when we made the
transition. But every time I've checked, this seems to be the case.
The US Magellan Mission to Venus
returned much larger-scale satellite images using Synthetic Aperture Radar (SAR) and topography and
bathymetry as well -- of darn near the whole planet. The SAR images are at a spatial resolution
of about 75m, and because the polarisation of the returning radio waves was recorded along with
the intensity, a lot more information about the surface material was recovered. Also, the
Magellan mission was the most effective NASA mission to date, in terms of GB of data recovered
per dollar spent. It was done on a shoestring.
Slashdot Mirror
Wellll....what you're describing is an attempt at knowledgable and responsible use. Some of that knowledge, which gives you understanding of how careful you must be, as you have described, is gained in the very type of clinical trials required by the FDA approval process. Unfortunately, where clinical trials are perceived to be biased and regulation perceived to be unnecessarily draconian (criminalised, for example), the only way users of those substances find out the real level of care that needs to be exercised is through trial and error on human subjects, and the results of their "experiments" are only be conveyed through rumour and anecdote-- the legendary bad trips you hear about, people winding up institutionalised or dead, through uh, not exercising due caution.
Even in the unregulated herbal preparations, the quantity of the active ingredient can vary wildly from batch to batch, which can make responsible use more difficult. Regulation would ensure more consistency from batch to batch, along with published guidelines on responsible use (no different than the dosage recommendations on a box of aspirin!) which can prevent others from unknowingly using the herbal preparation in a way that would harm themselves and others. So, in a lot of ways we actually agree on the fundamental issue.
I used to pop a couple Sudafed myself, once or twice a semester, to help study--a cup of mah huang tea to clear your head: that sounds even more reasonable! But if you've ever had to be the responsible family member dealing with a parent or sibling who has abused ephedrine, alcohol and other natural, organic and/or legal psychtropics irresponsibly over a long period of time, you might feel differently about the importance of the importance of testing their effects (particularly the long-term effects of prolonged use!) and regulating their use.
Someone who has become inured to rather massive daily doses of a tincture of mah huang is doing physical damage to their heart, has developed a physical addiction to the stuff, and does a lot of social and emotional damage to the people around them. And they can become violent. The constant sleep deprivation alone would be enough to induce serious psychosis. And yet, because it's "natural and organic" they think they can take as much of it as their addiction demands. There's no warning on the label!
I think you'll agree that the heavy-handedness of the FDA's approach to some of these substances only polarises and politicises the issue (and unfortunately they're particularly fond of slippery-slope arguments and other logical fallacies in their debate, which doesn't serve to convince anybody!)-- but at least the public debate gets the idea out to people that they do need to be extremely cautious. If the FDA rather conducted a campaign to distribute credible and balanced information on the basis of unbiased clinical trials regarding some of these substances, they might be far more effective in pursuading people to exercise an appropriate level of caution, and thus serve the public interest more effectively.
Well I used to update our /etc/hosts (in Unix, we don't use the suffix -- you
must have been on one of them VMS machines, calling it HOSTS.TXT!)
every friday without fail--
but then, campus networking would do the (long, slow) download from sri.nic.arpa for
the benefit for the rest of the sysadmins, plus you could get just a patch and
apply the diffs -- so it wasn't that big a deal to get
it over the network, no hours of babysitting an FTP link back to the mothership
SRI. Sort of like the way DNS actually works now -- like a
phone tree.
I figured they got the idea of how to set up the DNS distributed hierarchical database bits by studying the pattern of how people actually distributed their hosts files -- and wouldn't it be nice if they'd only have to distribute the changes: just like sending out weekly patches. Plus ca change, plus ca change pas.
When we got ahold of the first alpha and beta versions of BIND in the mid-80's, downloading the hosts table was still preferable because there were just too many bugs in BIND at that stage. It's kind of annoying that so little stuff is set up to fall back to the hosts tables properly anymore.
Thanks, Eric. I had to deal with someone close to me who was essentially addicted to ephedrine through daily use of "Mah Huang" aka ephedra sinica, a natural herbal supplement, the active ingredient of which is ephedrine -- which is no less harmful than crank. It can be just as deadly, too -- an overdose can be fatal. Way, Way bad!
pseudephedrine is the manufactured ingredient, the main ingredient in Sudafed, a leading decongestant. The same people that wouldn't take a handful of Sudafed will go ahead and take the equivalent dose of mah huang, because it's natural and organic. So is deadly nightshade. Not a great idea.
While it would be a shame if every herbal tea company were regulated into oblivion, its also clear that some "natural organics" can be quite dangerous (tobacco, psilocybin mushrooms, peyote buttons...)-- not to mention all kinds of unnatural inorganic treatments people try. Prior to the founding of the FDA there were some truly dangerous quack treatments -- electrical shocks to the nads for STD's for example. Unscientific, dangerous and quite scary stuff!
It takes time to complete FDA studies, and even then it's often not enough. Side effects can take decades, or even generations to show up.
Although not mentioned in the article, licensing costs per unit do play an important role in many companies' decision. I know of two companies here in NZ who were offered substantial discounts on the OEM licensing of WINCE on their devices only after considering Linux (for access to its TCP/IP stack, and other comms facilities). If you're planning on selling like 100 thousand to a million units, the difference between 10 bucks NZ per unit licensing fee and 3 bucks NZ per licensing fee makes a huge difference.
Of course, zero dollars per unit is even better, and access to RTOS source for zero dollars is even better, but it turns out that it's perceived by companies making these devices (who typically often have more EE's who happen to know how to program, than, say, linux kernel and device driver experts, or experts in some other RTOS) that it's better to take a small hit (3 bucks NZ per unit) on the proprietary embedded OS per unit than to have to develop the expertise in-house that they would need to in order to really take best advantage of an open source RTOS. It's when they're looking at having to take the big hit (10-15 bucks NZ per unit) that Open Source becomes more attractive, but that's precisely the point at which M$ is willing to lower their price per unit on WINCE.
Were that it weren't the case. What we really need is a big player who is willing to actively offer to these companies licenced support on an embedded linux at a lower cost than what M$ can do. By "actively" I mean having people on staff who will phone up the engineering managers of these companies and make a deal with them to supply kernel and device driver support, and to train their staff at a lower cost per unit than M$ will charge for WINCE. Then we'll start to see greater growth in the embedded linux market.
It's the steep learning curve for Open Source RTOS and the perception of lack of ongoing support that makes these companies willing to pay for proprietary embedded OS's, unfortunately.
Time and time again, we've seen M$ offer special deals to large organisations that "decide" to use OSS by decree -- governments, universities, companies. (Could this be the motivation for issuing these decrees on the basis of price alone in the first place?)
We've also seen M$ or their proxies (e.g. SCO) take steps to punish organisations that stick with their OSS decisions. The threat implicit in the "ISC"'s choice (and shame on them for appropriating the good name of the real ISC) is that the first hint of any problem with OSS, and they'll raise a ruckus in the media and try to discredit the public officials who did not choose " the best " software for the job, but made an "ideological" choice.
The only argument that can stand up to this onslaught is that data formats need to be open, so that the owners of the data can maintain their ownership. This argument has been made brilliantly in other contributions to this discussion. We might add to that: the owners of the data need to be able to see the source code of the programmes and operating systems (particularly the network components) which manipulate and communicate those data in order to avoid theft, misuse and misappropriation of those data.
Australia and New Zealand have exceptionally strong privacy laws -- and these laws are enforced. People, government bodies, and even large corporations with deep pockets take these laws very seriously, even though Echelon seems to be exempt ( NB: This is a different discussion.). One way that South Australia could help itself stick by its decision to use OSS in the face of these lobbyists would be to refer to its own privacy legislation as the prime driver for OSS, rather than price alone.
Oh! How very delicious, indeed!
When I was a newbie Unix Sysadmin in the mid-eighties, it was at a Very Large University that had been given an IBM 3090 "supercomputer" (while the administration, whose salaries were paid for by IBM Corp, purchased a second for full price , at a time when typical academic discounts from Sun and SGI were up around 50%). Well, there were a number of IBM employees "advising" University IT services full-time with offices on campus . They were there to squash any and all use of non-IBM gear, they were.
IBM didn't really have a Unix offering at that time, and the faculty were just clamoring for Unix mini's -- Suns, SGIs, DEC VAXen running BSD 4.2/4.3, Apollos, HPs -- even PC's running XENIX. The faculty found it was more beneficial to their research projects to buy a smaller computer but have it dedicated to the project, than to have to buy time on the University supercomputer. For one thing, they'd have the hardware for as long as it lasted, and have, well, root access. And they could hire monkeys like me for peanuts to keep them running -- on the network!
Well, my installing BSD on VAXen and keeping a network of Suns and SGIs running on the network made me none too popular with the Brainwashed-By-Big-Blue Brigade-- much as my putting cygwin on Windows boxes and occasionally whiping Windows altogether with a nice Linux install makes me none too popular with the MSCE's that infest corporate IT department these days.But in academics, as well as in business, it's the Golden Rule: the ones with the Gold make the Rules. By bringing in research grants, the faculty, who wanted unix boxes, were making the rules. Also, since much of the money was coming in from DARPA and Friends, who all championed BSD (having funded its development) we had the funding agencies to refer to as well. But the B-B-B-B Brigade would continually try to sell us time on the 3090 -- and we would be, like "get your eyeballs off of my stack, jack!"
I recall numerous acrimonious meetings with the BBBBB where they would point to this wonderful "gift" of the 3090 as obligating us to use it -- at which point we would counter with "Well, if it was running UNIX, we'd consider it..." They'd come up with their FUD to the tune of "Well, IBM is working on Unix versions..." (referring to AIX which was vaporware at that stage, and a BSD RISC machine that unfortunately never got off the ground).
But BOOM! We'd hit them with "Why not just install UTS on the 3090?"
Oh! The dirty looks we'd get for that one! Talk about hitting a raw nerve!
But now, IBM is our new best friend. The FUD Fighters and Champions of AIX and Linux.
It is way beyond ironic. It is so deeply satisfying!
Now IBM is famous for its interdepartmental rivalries. I do sometimes wonder if our little blows against the empire at that stage had anything to do with the ultimate rise of the groups, internal to IBM, that were behind the development of AIX.
The truly ironic thing, though, is that the technical sophistication and security features of the PPC chipset and OS/400 systems architecture are really starting to impress me as being quite a bit better than what either linux or unix on any hardware platform ever had to offer. *nix is just starting to get serious database-tuned journaling file systems, stable security implemented, VM's (or LPARs) to your heart's content, and use of an instruction set that can directly manipulate tables of 64-bit hash keys (on the PPC anyway). The AS/400 has had these things for a looooong time. So...maybe we were wrong back in the 80's, and IBM had it right the first time.
Truly ironic.
This is great, great news. I drove through Yellowstone and half of Wyoming on a tape of Twin House. One CD I still haven't been able to find is Lambert, Hendricks and Ross -- a recording they did that had "Cloudburst","Centerpiece" and "Twisted" (amongst others).
My favorite Coltrane has always been Giant Steps , which shows up in the bargain bins all the time, as does a CD that has both Sonny Rollins albums Tenor Madness and Saxophone Collossus .
There's a delightful duo of Earl Hines and Stephane Grapelli out as well, a single session, their first (and last) meeting, where they do just an incredible version of "Moonlight in Vermont."
Besides being completely unprofessional, is totally and completely morally wrong to initiate and maintain sexual relationships with co-workers and clients. And we can add subordinates, contractors, direct supervisors, professional colleagues, students (undergraduate, graduate and postdoctoral), faculty and administration to that list. Even where the personal relationship pre-dates the professional relationship, there are serious moral, social and professional issues -- issues that simply don't exist when the two spheres are kept separate in fact as well as in the shallow "maintaining a professional image" you describe.
What you describe is more like living a double life. You're the same person when you are home versus when you are at work. If you're not operating from the same set of values and principles in both spheres, you lack personal integrity, and I know from experience to stay well away from people like that.
Now I've heard certain women's refusal to put out for the boss ascribed to the woman's "immaturity", which is just pathetic. A guy has no business trying it on with her in the first place, but then tries to reposition his own lack of personal integrity as "maturity". It's not "mature" to expect women engineers, mathematicians, programmers, scientists, clerk-typists -- what ever-- to put out. It is morally WRONG . If the guy that much "in love" with her, he can bloody well recuse himself -- change jobs. Work somewhere else. And if he's not that much in love, he can bloody well keep it in his pants.
It's not "immature" for a woman to know the difference between right and wrong. A female who does is a "slut", and a female who does not is "immature." Given that you have the choice between being denigrated no matter what you actually do , the only rational choice is to do what you know to be morally right regardless.
Ethically, the situation is very similar to, say, a police officer amongst a group of corrupt police officers. If he does not take a bribe, the other police officers will become afraid that they will be exposed themselves in their corruption, and they will do whatever it takes to get rid of the clean cop. If he "goes along to get along" he will not be able to respect himself in the long run, and he may even eventually get caught out engaging in the very corruption that he so reluctantly went along with in the first place. Either way, he's damned in the eyes of the world. His only way out is to do the right thing regardless of the consequences. At least he will be able to look himself in the mirror every morning. He certainly won't have to write elaborate memoirs and novels to justify his behaviour.
Now it's a real shame that Ms. Ullman just doesn't know the difference between right and wrong. A real shame. I feel sorry for her, I really do. I feel doubly sorry for her that her moral relativism is celebrated by Salon and the NYT, because it will just take her that much longer to figure it out, and she'll take others down with her into her little cesspit.
If she did know the difference between right and wrong, and had kept up with modern code instrumentation and debugging tools, she might still be a programmer. While it's unclear whether she left the field primarily because she'd been screwing around, or because she wasn't keeping up with her field, it was probably a combination of the two. We know both cases to be true.
Since when is it inhernetly unprofessional to maintain personal relationships with co-workers/clients?
Ever since Potiphar's wife came on to Joseph, and Joseph had to say "thanks, but no thanks" and suffer the consequencs. It's not OK. You don't screw the crew. End of story. It's not good programming, and it's simply not professional.
A memory leak is a failure to deallocate memory causing the program to consume ever more system resources.
Which causes transient failures, typically at different locations in the code every time. Fact. You obviously have never had to work with code that has a memory leak. And a buffer overflow is a type of memory allocation error.
You said: lemme introduce you to a few abstract concepts like fiction or artistic license.I don't believe the narrator of "Close to the Machine" is Ms. Ullman herself.
in response to my comment that in "Closer to the Machine" she gets intimate with clients and co-workers during the project even
Mr. Jpeg: did you read it? Closer to the Machine is a MEMOIR.
From the spamazon Editorial Review of Closer to the Machine by Cliff Barney:
Read it and weep. What I find so disturbing is the non-technical community's (read: Salon, Book Editors) lack of censure for her non-professional approach.And, The Bug--oh!! A bug that only happens sometimes at different places in the code? Christ on a bicycle, hasn't she ever fixed a freakin' memory leak before? Corruption she's clearly familiar with, but this kind has a blindingly obvious Simple solution. Instrument the code with Purify or Insure++, or Electric Fence or at least check where and how memory is being allocated and deallocated. This isn't rocket science, you know. Oh well, guess that's the difference between her "20 years of programming" and my 25.
Sure The Bug is fiction, but it's fiction based on a truly lame approach to debugging.
In "Closer to the Machine" she gets intimate with clients and co-workers during the project even.
Extremely unprofessional.
And really...yuck.
Yah! And I can see Scott Adams doing the writing for it.
There was a British series called "Attachments" that actually had some decent programmer content/activity, though it was dominated by dotcom management pratfalls and consequences that we've all seen in real life by now, so why make yourself sick watching it on TV.
What's more interesting is the "junkyard wars" format, with Robot Wars and Robotica. And yet you don't get very good representation of the interesting part -- they're presented like Pro Wrestling.
How do you illustrate the process of problem solving in a visually compelling way? Better yet, how do you engage the viewer intellectually in the process? There's the dramatic twist, the quirky character, the suspense -- but the most engaging it gets, really, is in the whodunit or the spy "thriller". And these are so formulaic, predictable and worn-out by now, that there's just no fun in them.
Science and Techno documentaries are by far the worst-- their Breathless Admiration of The Great Man Of Science and His Great Discovery, or This Wonderful New Technology And How It Will Change Our Lives. How utterly boring.
While it's preferable when females write intelligent things about the scene (vs. writing stupid things about the scene ala aimee deep), and are cast as intelligent females in fictional accounts of hacking (as in Digital Fortress ), or even as interesting characters in computer games (Lara Croft) "The Bug" is still a female writing about computers, rather than writing software , developing algorithms , modding hardware etc.
OTOH, any progress is good, and since progress in the area of "the image of female geeks" requires a substantial change in the culture , perhaps the best place to promote this change is through cultural means.
The terrific thing about The Bug is that the author has written code, so she's writing from experience so we don't get the kind of nonsense we saw in, e.g. "Swordfish." Swordfish was just crap. I mean, come on, why all the blood and guts surrounding gaining physical access? If they had to gain physical access to the servers, they weren't such great hackers. Doh! Plus, much as I like Halle Berry the thing her character did was social engineering--she had to bring in the male gun techie to do the real work. eeeeeyuck! Again, if her social engineering skills were that great, why didn't she just apply it to the problem at hand, rather than the complex and messy techniques the Travolta character came up with. This was the only regard in which Swordfish was realistic: the gal had the by far better skills to solve the problem simply and quickly, yet the solution that got implemented was some big messy over-complicated plan developed by the guy. Typical !
By contrast, I just loved Angelina Jolie's character in "Hackers," errors of fact and ludicrous storyline notwithstanding. She played a great character in Tomb Raider as well--too bad about the muddled plot. And who could forget Carrie Anne Moss' SSH-1 'spoit in Reloaded?
It's when Ullman is brought in as the technical consultant on the Hollywood production of The Bug, and perhaps even Digital Fortress, and we consequently see the first believable and intelligent movies on the topic, that we'll finally see a triumph of substance over style. And I hope they get Angelina Jolie or Carrie Ann Moss to play the lead!
On one project, we used PostGreSQL's GIS extensions, PostGIS under SuSE for the prototype, as the prior GIS DP methodology was to do all the GIS processing by hand on a windows desktop--which read and wrote .shp files. Gross! After developing a prototype
DP stream in PostGIS, which is OGC compliant,
it was fairly simple to migrate the DP methods (all SQL with OGC-compliant GIS data formats
and stored procedures) to DB2 Spatial for the bulk processing, which could handle even
larger data volumes, and much, much faster. By about an order of magnitude.
Hours instead of days. Is it an "open source failure" to prototype a process using
an open source tool, then migrate it to a proprietary product that's actually better?
Both still ran under SuSE.
It demonstrated the utility of doing the GIS processing required with a spatial
database rather than a silly little pointy-clicky windows app. Without the OGC standard
that both PostGIS and DB2 Spatial adhered to,
however, it would have been a real nightmare.
LandSat 7 is simply not as capable of a sensor as some of the others out there. Shutting it down without shutting down better sensors is wasterful and strategically pointless.
I'm not sure about that. For one thing, it's more plausible for an old satellite to "malfunction" than a new one. The other thing you need to consider is timing and coverage. Just because satellite A is better than B doesn't mean that it will be where you need the data at a particular time. No matter how you slice it, the data volume and coverage from A+B > the volume and coverage from A, unless the data from B is literally worse than useless.
Your "simple inductive logic" reminds me of an old joke: A mathematician, a physicist and an engineer ...
I know. That's why I identified formulating projections on the basis of past known events as inductive logic, rather than deductive logic. We're calculating probability density functions here, not proving that something is definitely so or not so.
By the way, can you give any substaniated examples of a satellite being shut down permanently when it was putting out data of military significance?
Yup! SeaSAT failed after 116 (or 106, or 99, depending on which source you believe) days of operation. The person doing the analysis showed me the pictures. I was just an undergraduate at the time. The high-res SAR data stopped coming through well before the low-res -- odd, considering the failure of the satellite was attributed to a massive power failure. The data were militarily significant for the better coverage of ocean floor topography than was practically feasible to gather with sonar -- again, coverage is key here, not resolution. Sonar gives you better resolution, satellite geoid and topography gives you better coverage, particularly in areas where it's difficult to conduct bathymetric surveys--around Novaya Zemlaya for example. Subsurface topography is the widely acknowledged military significance of these data. The person doing the analysis was specifically asked to decimate these data prior to publication-- remove the spikes. Sub holes, strategic canyons and particularly "anthropogenic time-dependent spikes in the sea surface topography". Sub wakes. He did it. I would have, too.
The later GeoSAT satellite data were held by the US Navy and not declassified until after the Cold War.
This is the perfect conspiracy theory: it's almost entirely plausible, almost impossible to refute, and we want to believe it!
Reasonable suspicion based on past known behaviour does not a "conspiracy theory" make. Every time a remote sensing satellite goes black, it's worth wondering of what tactical or strategic value was the data. And to do this well, you need to know what image processing and multisensor fusion algorithms are currently being used, by both your own nation, and your nation's enemies, as well as what other data they have available. It's not just the raw data, bucko.
On the other hand, I can get a pretty good aerial view of Downtown Baghdad any time I want it.
Yes, but what about Bankok and all of Brazil? What about March 2000 vs June 2003, i.e. What is your coverage like over time? Ever wonder what's going on just out of range of a single image? What went on the month before or the day after? What the area looked like in a mulispectral, SAR or IR images? What if your multisensor fusion algorithm is ten times more accurate when you add low-res multispectral to your high-res optical? What if it becomes ten times more useful when you have three images to compare over time, in the same area, versus just one? What if your algorithm has far greater strategic value if part of the data are believed by your opponent to be simply unavailable due to ostensible satellite malfunction? What if half of your own functioning satellites were taken down in a war? Wouldn't you be glad to be still getting the data from the ostensibly malfunctioning ones?
These are actual questions pondered in actual meetings. I have been presented with them in a technical setting, in the development of actual image processing applications. It's hardly a "conspiracy theory" to say that these questions are asked.
20-20 tunnel vision is of no use when there's a truck full of explosives coming at you from left field. You need your peripheral vision for that. And it's the missile coming right at you that's the hardest to measure the velocity of. So the more points of view you have, and the more measurements over time you can make, the better off you are, from a defense standpoint. As an American Citizen, I happen to like my country being well-defended, so I don't think it's necessarily a bad thing if LandSat 7 went black for some reason other than a straight malfunction. But it does make me wonder.
Actually, I worked on several image processing projects for the military, and we certainly did use LandSat data. And SPOT data (optical band) and SAR data (K band and X band mostly) as well as IR data.
The advantage of LandSat data is the broad spectrum of data returned, not the resolution. As a consequence, LandSat data alone has little tactical use, but it has tremendous strategic value -- particularly when geolocated and registered with data in other bands, and in conjunction with other data. In one project I did for the Comprehensive Test Ban Treaty Verification Organisation in Geneva, the challenge was to develop criteria for distinguishing mining sites from non-mining sites using satellite imagery. What does this have to do with A-tests? you may wonder. An underground explosion could be part of a mining or roadworks operation, or it could be a nuke test.
You've got the location of the explosion easily enough from the seismics, and it's easy enough to distinguish from an earthquake by its distinctive P/S wave ratio (explosions have almost no shear wave component, it's all compressional). Now how can you tell if its an ongoing mining operation without actually visiting the site? First you geolocate and register your LandSat, SAR, AVHRR and SPOT data to each other in the region of interest. Throw in some vector road maps and topography while you're at it. Imagery from different days, months, years, decades in the same area is also quite useful. Now you can either sit down an analyst in front of the data, or you can develop algorithms for identifying mining sites from various combinations of imagery. When you're done, let me know. LandSat data is tuned for collecting land-use information. Tree cover, grasslands vs. exposed rock for example. Clearings in the jungle that weren't there before. Desert areas that suddenly change to vast warehouse complexes well away from the largest roads and typical commerical trucking routes. Get the picture?
It is of tremendous strategic value to unobtrusively monitor land use over time, over large areas, for all sorts of military applications. Other data are better for tactical applications in a silly little game of soldiers, true--but you're not going to even want that level of resolution and targeting for determining new developments. The world is a big place. Where do you look first, and what kinds of anomalies do you look for? What anomalies are potentially of strategic significance? Quick, give the answer without LandSat data. Not as easy now, is it?
And as for calling it a "conspiracy theory" -- it's rather well known that there exist American satellites that have been said to have malfunctioned that have certainly not, because the data being returned was found to have military, strategic or other significance. The LandSat 7 "malfunction" could well be another instance. No conspiracy there. Satellites go black for different reasons. Malfunction is just one of them.
Look at it this way. I leave five dollars on my desk and it disappears. The thief is caught on camera and given a warning. A week later I leave five dollars on my desk again, and, again it disappears -- but this time the thief is not caught on camera. Is it "a conspiracy theory" to say, well, this guy was caught stealing once, and he was in the area at the time, so of course we're going to question him. Does calling this reasonable suspicion based on past behaviour a "conspiracy theory" wash? No. It's just simple inductive logic. Get over it.
You have obviously never seen Landsat data before. It is of little or no military value. There is no conspiracy here. Satellites break. Get over it.
Actually, I worked on several image processing projects for the military, and we certainly did use LandSat data. And SPOT data (optical band) and SAR data (K band and X band mostly) as well as IR data.
The advantage of LandSat data is the broad spectrum of data returned, not the resolution. As a consequence, LandSat data alone has little tactical use, but it has tremendous strategic value -- particularly when geolocated and registered with data in other bands, and in conjunction with other data. In one project I did for the Comprehensive Test Ban Treaty Verification Organisation in Geneva, the challenge was to develop criteria for distinguishing mining sites from non-mining sites using satellite imagery. What does this have to do with A-tests? you may wonder. An underground explosion could be part of a mining or roadworks operation, or it could be a nuke test.
You've got the location of the explosion easily enough from the seismics, and it's easy enough to distinguish from an earthquake by its distinctive P/S wave ratio (explosions have almost no shear wave component, it's all compressional). Now how can you tell if its an ongoing mining operation without actually visiting the site? First you geolocate and register your LandSat, SAR, AVHRR and SPOT data to each other in the region of interest. Throw in some vector road maps and topography while you're at it. Imagery from different days, months, years, decades in the same area is also quite useful. Now you can either sit down an analyst in front of the data, or you can develop algorithms for identifying mining sites from various combinations of imagery. When you're done, let me know. LandSat data is tuned for collecting land-use information. Tree cover, grasslands vs. exposed rock for example. Clearings in the jungle that weren't there before. Desert areas that suddenly change to vast warehouse complexes well away from the largest roads and typical commerical trucking routes. Get the picture?
It is of tremendous strategic value to unobtrusively monitor land use over time, over large areas, for all sorts of military applications. Other data are better for tactical applications in a silly little game of soldiers, true--but you're not going to even want that level of resolution and targeting for determining new developments. The world is a big place. Where do you look first, and what kinds of anomalies do you look for? What anomalies are potentially of strategic significance? Quick, give the answer without LandSat data. Not as easy now, is it?
And as for calling it a "conspiracy theory" -- it's rather well known that there exist American satellites that have been said to have malfunctioned that have certainly not, because the data being returned was found to have military, strategic or other significance. The LandSat 7 "malfunction" could well be another instance. No conspiracy there. Satellites go black for different reasons. Malfunction is just one of them.
Look at it this way. I leave five dollars on my desk and it disappears. The thief is caught on camera and given a warning. A week later I leave five dollars on my desk again, and, again it disappears -- but this time the thief is not caught on camera. Is it "a conspiracy theory" to say, well, this guy was caught stealing once, and he was in the area at the time, so of course we're going to question him. Does calling this reasonable suspicion based on past behaviour a "conspiracy theory" wash? No. It's just simple inductive logic. Get over it.
During the Reagan administration, when a high-resolution statellite instrument to measure the earth's geoid and topography was suddenly found to be extremely useful in locating submerged submarines (by way of their wakes) it, too, suddenly "went dead." I knew the guy at Lamont-Doherty Geophysical Lab who discovered how to recover the submarine wakes from these data. Funny how only the high-res instrument (the one that could detect submarine wakes) suddenly "went dead." The low-res instrument continued to return data. It was an open secret in the geophysical community that the high-res instrument didn't actually have a malfunction. Funny how the US won the cold war with a few years after that, too. Hrmmm.
It was also the Reagan administration that privatised LandSat -- after spending billions of taxpayer's dollars to develop and deploy the LandSat satellites and do additional TM work from the space shuttle, suddenly all of the imagery was owned by a private company. And government-sponsored projects, instead of paying like $350.00 per scene, suddenly had to spend $3500.00 per scene. Double that to account for "University Overhead." What I want to know is, why, after paying for the development and deployment of this technology, do we (as taxpayers) then have to pay for it again when a project is formed to analyse these data? Didn't seem right at the time. Still doesn't seem right.
But I honestly doubt the LandSat 7 TM instrument actually went dead. It was probably found to be returning data of military significance, and why bother with the political rigamarole with the scientific research community, not to mention the delay involved with classifying data -- when you can just claim the thing "went dead"? After all, who is going to make the trip to the thing itself to verify the claim that it "went dead"?
Yah. SuSE did cut back its US ops a few years back. Too bad for the US. Here in NZ, we have neither a RH or SuSE office, so "whether-or-not-they-have-a-local-office" just doesn't make a difference in the "RH vs SuSE" debate.
One thing that does make a difference (to us) is the overall management of the company itself, which will affect its survivability and business reputation. RH was involved in a pump-and-dump stock scam a few years back, as was VA. Not so for SuSE -- they cut back their personnel expenses when it was a good idea to do so -- just before the dot-com bubble done dot-bombed.
Don't bother with going above his head or breaking whatever you've got going now. Rather:
It's like bowling for dollars! Set 'em up--then Knock 'em down!
I mean, if this manager had any skills, she'd get both you in-house and the consultant working on the solution "to see a demo", and saw what worked best, without making any concrete decisions or promises until it was absolutely necessary to make a decision. In the interests of (cynical spin on the positive approach here) "brainstorming" she'd flatter both of your sets of ideas in meeting after meeting, getting you to give away your best ideas in the course of "requirements capture" while the conslutant takes them, incorporates them into its own products, lands the fat contract, and gives her a fat kickback and/or perquisites (read: boozy lunches at the very least).
I mean, we should all be so lucky as to have a manager as honest and forthright and decisive as yours.
We switched from RedHat to SuSE several years ago.
Our reasons for making the transition were:
- SuSE's stable enterprise/server editions are far less expensive than RedHat's
- DB2 UDB and Oracle are both Certified for SuSE enterprise server editions
- More specialised sub-distros available if you don't feel like twiddling
and paring down the full distro yourself.
- I supported RH from 1997-1999 (IRIX, SunOS, Solaris, BSD 4.2 and 4.3 before that)
My opinion is that the support database for SuSE is better than RH,
and that SuSE's support is much, much better -- and not nearly as often required --
compared to SGI's or Sun Microsystems.
- When we made the transition from RH to SuSE, SuSE was streets ahead of RH in security.
While not entirely up-to-date,
Marc Heuse's
article is a succinct and readable yet technically comprehensive introduction.
Areas in which RH and SuSE are roughly equal are:As we're primarily an AS/400 development shop, with Linux just providing part of the infrastructure, it's been fortuitous that our choice, SuSE, has turned out to be the most stable distro for the AS/400 and PPC platforms.
We dealt with no salesperson in either case. Just bought the disks and support packages we felt we needed, and based our judgement entirely on what versions of what were already available on the latest release. Possibly because the RH and SuSE distro cycles were out-of-synch with each other, the latest SuSE had the more recent patch levels when we made the transition. But every time I've checked, this seems to be the case.
The US Magellan Mission to Venus returned much larger-scale satellite images using Synthetic Aperture Radar (SAR) and topography and bathymetry as well -- of darn near the whole planet. The SAR images are at a spatial resolution of about 75m, and because the polarisation of the returning radio waves was recorded along with the intensity, a lot more information about the surface material was recovered. Also, the Magellan mission was the most effective NASA mission to date, in terms of GB of data recovered per dollar spent. It was done on a shoestring.