Your daily requirement for vitamin A more than doubles when you use your eyes for close
work every day. Eye strain is a symptom of vitamin A deficiency. Munch on a few
carrots and cashews during the day. Get some sunlight for the vitamin D. Cashews
have calcium, which improves the absorption of other vitamins. Have a glass of V8.
Canteloupe for breakfast. Plenty of fresh, raw fruits and vegetables, and drink water!
8-10 glasses a day. A balanced mineral and vitamin combination regime will take over
a month to really show its positive effects, so keep up with the vitamins, and get
the extra vitamin A you need with carrots and sunshine.
Also, instead of just inverting your colors, you can go to green-on-black or
orange-on-black for text and code. Most relaxing. All the other advice here
(looking away from your screen frequently, getting up and walking around every
45 minutes or so, using saline eyedrops and eye wash) is all good stuff.
Some people flaunt the numbers "36-24-36" other fluant "IQ of 160" either way your are stil trying to show off and live through your children.
They're not my kids, they're my neighbors' kids. And, being
so bright, they're quite interesting young people.
What you choose to promote, and what you choose to deplore
is literally what makes you a unique human being.
You can choose
what you want. You can even choose to remain ignorant of your own
capability for discernment. That's your choice.
I choose
to promote girls and womens' education and accomplishments, particularly in science, engineering, software development
and mathematics.
I choose to deplore
things that cheapen or degrade those accomplishments.
One of those things is Aimee Deep's
interview, which reveals her self-absorbed attitude,
her unprincipled upbringing, and her lack of knowledge
of the technology and her misrepresentation as a "geek girl"
A woman using her body as another tool in her arsenal does not neccesarily indicate she is not intelligent. Actually a woman who can and doesn't is actually quite ridiculous.
In the spirit of respectful debate, allow me to offer a different
perspective. We may have to agree to disagree, which is fine.
First of all, the topic isn't what you want in a personal
relationship. The topic is to what extent a female
scientist, engineer, software developer, artist, musician --
professions in which there is a tangible, concrete product to design,
create and deliver -- can or should be "using their bodies" to "get ahead".
What does it say about
the quality of the product and the intelligence and integrity
of the people behind
it when your highly experienced, highly trained technical consultant
has to literally get her
dress up over her head in order to close the sale? " Wow man, that is just soooo lame!" in the parlance of our little
friend Aimee.
"Simply unprofessional," is how an adult might put it.
If your only criteria for success is how far ahead a person gets
or next month's bottom line,
then sure, why shouldn't she hand out BJs with the RFCs, RFPs and SLAs. OTOH, if your criterion for success is to
build a solid reputation for
your profession, for your firm, and for yourself, then what looks "ridiculous"
are the cheap and sleazy tactics your competitors will
stoop to.
So, while I agree with you that being well-presented or
even stunningly beautiful is a terrific asset,
being cheap and sleazy is not.
Ask yourself: do you respect aimster/madster more
or less for the founder's putting his
underaged daughter in a bikini up on
his company's website? Sure, it may attract attention in
the consumer market, and
they may get some short-term mileage out of it.
However, if you were a
CIO or one of the Joint Cheifs, would you commission
the company behind it --Johnny Deep's -- to develop a military comms system or a corporate procurement system based on the
underlying technology they developed with aimster? Would
you want miss Aimee directing the project? Hmmm? Probably not.
The technology is there, but Aimee doesn't really understand it.
And what's a girl with her level of
personal and professional integrity going to
do with your classified or proprietary system if someone
offers her money for it? What will her price be, if all's it
takes is a bit of attention on the internet
to get her to take off her clothes?
Look at her goals and values. She
said it herself: "it's all about ME"
Completely self-centered. It's how she was raised, and
who raised her.
Look at the quality of aimster's
business relationships, and relationships with its employees.
In the toilet! Don't you think that has something to do
with the kind of people running the company? You know,
the same kind of people that would put a picture of their
own teenage daughter half-naked up on their website to promote their product.
She can choose to go along with it, or she can choose not to.
I would have a lot more respect for her
if she at least understood the technology behind aimster's
products (she dodged a question about that in the interview). But
you,
And the "using her body" bit that you suggest -- let's see if I
can find something positive in it. HIV positive, maybe.
On balance, it's unhealthful, it's deplorable and it's unprofessional.
Any female scientist, engineer, software developer,
artist, mathematician, musician
who feels she has to do things like that to "get ahead"
is truly, truly pathetic. A real lamer, whether she's any good
at what she does or not. If she's good her chosen profession,
she shouldn't have to engage in the oldest profession.
I would like to know what the ladies of slashdot think of this Aimee Deep girl.
Well, since you asked...
Being a teenaged girl does NOT let her off
the hook. You are a combination of what you do and how you
communicate it.
Aimee Deep is clearly just a "scene whore."
Big deal. She'll probably grow up to be one of those women "in IT"
who've never written a line of code in their lives. Typical.
When I was her age, I:
had already been accepted to several top engineering schools
was already attending Cornell's College of Engineering (not far from Cohoes)
was already working as a programmer on campus
had already completed a semester of undergraduate CS
had been programming in high school computer club for several
years. That's programming, not surfing.
My neighbor has 2 daughters. The younger has an IQ of 160,
and builds and programmes Lego Mindstorms with Linx/esterel,
and the older programmes in PERL under linux and is training
to be an airplane pilot. They're 12 and 16, respectively.
Its just plain wrong that all of their accomplishments
will only subject them to comparison with a stupid girl
like Aimee Deep, "yes, maybe she can programme, but
how does she look in a bikini."
For crissakes, we train as programmers,
airplane pilots, engineers so that our work can be objectively
judged on its merits, not on the exposure of our breasts! If
we wanted to be judged on our breasts, we would have gone into
fields where there are no objective measures beyond
"36-24-36".
Touting a stupid girl like Aimee Deep as a "geek girl"
creates a situation where women who are highly trained, highly
educated, and have decades of technical experience--
get lumped in with the stupid little girls in the line-up. With an
undergraduate degree in engineering, a Ph.D in physics and 25
years of professional programming experience, I still
have to fight the "oh, look she knows what all these big words
mean, maybe she can write our documentation
for us, and hey joe, are you getting any off of her, nudge nudge,
wink wink" attitude.
Quite
frankly, I'm utterly disgusted at Aimee's father's putting her up
as a
cheesecake scene whore and then trying to claim she's some kind of
"geek girl" when she's anything
but. The interview only reveals her stupidity.
If she were a
brilliant programmer, engineer, pilot, physicist, musician,
artist, whatever, and
happened to be stunningly beautiful, it would be like, "well...
maybe her looks have helped her get ahead, but how is
that different than a tall guy with a gorgeous voice and beautiful
manners using his personal attributes to help sell his software?"
There's lots of good software out there, but something has to
work and something has to have been created .
This gal claims to be creative , but is she making
the music ? No. Is she writing the software? No.
Unfortunately, Aimee Deep is pretty
ordinary in the looks department, none too bright, and
definitely not accomplished in anything useful or
creating anything worthwhile. At best, she's a cheerleader for EFF.
yawn!
To address the number of devices they'll need, I'd
bet on their making the transition to ipv6,
which has been, unfortunately, stymied and postponed for years now.
Just demonstrating the transition in a rather large
real-world application
would be one of the more useful spinoffs. At the
very least, it will help keep ipv6 efforts alive.
yudit is quite nice,
as well as the new vim and emacs. An interesting exercise
is to run ascii, utf-8, and utf-16 LE and utf-16 BE (little and big endian, respecitvely) representations
of the same text (say a 2-line text message) through
% od
and see what's really being stored in them thar files.
There's also a whole bunch of useful tools in the
ICU (no, not
the Intensive Care Unit!) with links to the openl18n pages.
In terms of being extremely informative, from the top-level
overview of internationalisation of software down the the
greatest technical detail you can actually use -- including
a really useful set of software libraries with
source code provided , I can't recommend the
ICU pages
highly enough. Context plus details in context. A revelation.
He swaps out said drive, zero down time, and nary a performance hit because a hot spare came online. You have got to love that kind of service and uptime, and just plain reliability.
Yup! AS/400's (aka iSeries) are like the Energizer Bunny.
In the database wars, you have to remember that the chip the AS/400 is based
on has been native 64 bit for a long time (great for batch transaction processing on large tables--one place Oracle falls down big-time on
any platform) and
the instruction set is geared towards RDBs. What do you expect
from a company that's been building and processing databases
since the turn of the last century -- that's right,
Hollerith's cards were used in the 1900 census, which are, BTW,
the same size as a 1900's US dollar bill.
IBM learned a lot about databases from developing applications on machines that process enormous stacks of punch-cards mechanically--including searches, sorts and selects based
on various criteria. Unfortunately in the German census processing in the 1930's, one of these criteria they sorted, searched and selected
on was "who is a Jew?" -- and the
IBM punch-cards these data were recorded on were imprinted with
swastikas.
I wonder if anybody's looked at the business transactions recorded
in cuneiform to see if one could scan down the columns and
across the rows visually to
detect patterns and anomalies (much in the same way BA's look at
long columns of numbers in their spreadsheets). This would be the earliest example of data processing. Tremendous reliability of the
physical media, too.
They also propose that all computer systems should have an "undo" feature built in to allow harmful changes (either due to mistakes or malice) to be easily undone...
AS/400's have had this for a long time. Linux does, in the sense that
you can load and unload certain device drivers and modules dynamically.
But really, in terms of OS architecture and hardware, AS/400's have
been way ahead of their time for a long time. Worth studying.
Yup. The other way in which Sun's move is similar to SGI's is
that the last thing Sun has left that's "special" is JAVA--and
the last thing SGI had that was special was OpenGL and VRML.
Very nice stuff, use it all the time--
but neither technologies provide them with anything near the
leverage each had in the marketplace
when they also had the best hardware and
OS to do the job -- enterprise computing in Sun's
case, and 3D animation in SGI's case.
Another analogy is that Sun's move to the industry standard
X86 architecture is similar to SGI's attempts to move to
industry standard NTOS, then Linux. Both were a bust, causing
huge code migration issues for companies that had to make
the switch away from IRIX. Didn't exactly endear them to
thei existing customers.
The whole Sun/SGI story is really the last gasp
of the last wave of computing -- workstations and mini-mainframes
-- from the 80's.
Just as IBM's attempts to get into the workstation space in the 80's
was eaten alive by Sun, HP and SGI, and their attempts to get
into the mini-mainframe space were eaten alive by DEC.
What IBM had going for it, in terms of survival, was that it was
just so darn BIG. The failed attempts to get into the
workstation and mini-mainframe space were balanced by spectacular
success in the PC space while managing to hold on to the mainframe and midrange enterprise computing space (S390's and AS/400's -- now called what, Zseries and Iseries).
Remember when PCs were called "microcomputers"? IBM coined the term Personal Computer
for one of their products, and it stuck like Kleenex to your Hush Puppies.
These are absolutely terrific articles. Their distribution of an open source TCPA linux
module satisfies a lot of concerns and questions many of us
had about TCPA in a concrete and specific manner.
One concern still exists: that DRM and Palladium will be used
to create a "mainstream" set of M$ applications which give people
the illusion of security, while concentrating most of the information
and control in the hands of the few.
The most important
step people in the open source community can take next are to
get a system with a TCPA chip and start developing drivers,
firewall systems, proxies and applications that make good solid
use of the technology: tsshd, tsquid, tsftp, thttpsd, tbsd,
toggd, tnamed,
texim, tkonq...
If you've stumbled across evidence of
substantial and systematic bilking,
theft, fraud, etc. in a corporate database
on an utterly massive scale...
remember, fish rots from the head down.
Going up your chain of command is what
you have to do, but do expect severe and
immediate retaliation.
Just them knowing that you know what they've
been up to, by your routine data QA, is enough
to cause sudden complaints about your
"behaviour."
Remember, it takes two to tango, but only
one to squirm . Their
complaints are evidence that they're starting
to squirm. You need a plan now.
When the going gets tough,
the tough take notes . Keep
copies of things. You you
are going to need a well-planned
and pre-established "exit strategy", because
you will
be punished for doing the right thing.
While "Retaliation for Opposition to An
Unlawful Practice" is illegal, it will take you
3-5 years to prosecute your retaliation
case, while also giving testimony in
the civil and criminal cases the FBI or
Serious Fraud Office is going to be bringing
against them. You are going to need one
heck of a safety net.
So your order of business is:
Detect Evidence
Discuss with Spouse, Family, Religious Leaders
Document Evidence
Find out whose the best lawyer in the
State, if not the Land for handling your case
Copy Evidence,place under lock and key
Find another job, sell excess assets, cash in annuities
Report Evidence up Chain of Command
Enjoy Watching them Squirm!
Resign at the worst possible time for them
Provide Your Evidence to The Authorities
Going to the Press is a last resort
You have to discuss this with your spouse
and grown children as soon as you even have suspicions,
so that you can plan your exit strategy together. They
have to understand that you all might be a lot happier
in the Peace Corps or setting up wireless networks in
Africa, or living on a high-school teachers' salary
or grad student stipend.
If you belong to a church, mosque
or synagogue, discuss it with your pastor, priest,
imam, rabbi-- because, God help you,
you will need serious moral support when the poo hits
the ventillation system.
When you must report criminal wrongdoing expect
to get canned--for "other reasons" of course. You will be
surprised at how lame a case they'll be willing to make for
those "other reasons." So will the judge.
Child pornography
is criminal wrongdoing. Bilking legitimate shareholders
of millions of dollars a month is criminal wrongdoing.
A utility defrauding half a nation to the point that
its
factories are closing, its schools are cold and dark,
and
its hospitals have to turn away sick children is
criminal wrongdoing.
... Hint: for a job doing multitable correlates or joins on 100 GB to 1TB production databases each running under different
DBMS and OS's, Beliskner ,
you're most likely going to have to dump ODBC altogether, and implement
a comms standard over raw sockets because, besides being functionally
inadequately specified, ODBC slows everything down by at least an
order of magnitude -- which means the difference between a correlation
taking 10 hours or 10 DAYS. If it has to be done EVERY DAY, 10 hours
works, 10 DAYS -- well, you'll just keep falling further and further
behind.
And this is just bog standard corporate IT after a merger or
acquisition, because one of the
reasons companies underperform (making them ripe for a buy-out)
is that their legacy systems are such outdated poorly implemented
crap. Rarely
are the compatibility or modernity of the production
systems adequately addressed in the course of due diligence prior to the
merger or acquisition, and this is where they suddenly find they're
getting bit in the arse post-merger, or post-acquisition. Hence the
big bucks for the DB people, because every day of down-time would cost them
a lot more than your fee is to sort things out for them.
And yes, parsing addresses can be as simple as you say. Until
you get to international addresses that put the street address, city
and country in a different order. And the postal codes suddenly have
characters in them, and the variable length indicates varying degrees of specificity in the addressing (as in the UK). And the alphabetisation will not follow the same ordering as ASCII or EBCDIC encoding, so you
need to dub them all into UNICODE and applying the UCA (Unicode
Collation Algorithm) to get them to come out in the alphabetical order correct for the customer's country. What about when the result set
needs to be alphabetized in an order which is correct for several
different languages at the same time? And which transliteration are you
going to use for Thai vs. Arabic? Which address parser you
going to use for geolocating banking customers in the Phillipines
and Colombia when
most of the customers have not given their addresses to their banker--for personal security reasons?
But, yes, in the simpler cases, you do develop some
fairly standard ways of solving the standard problems posed by the
original commenter. That was one of my points, you might have
noticed. Thank you for
supporting it with a simple example.
Oh, and by the way, Beliskner, you've contradicted yourself in two
paragraphs. In one, you say that it's your full-time job to repair
data, and in the last line, you imply that it's not. I suspect the
truth is the latter.
Try using ODBC on joins between three tables, one with 57 million rows another with
200 million rows and a third with 1.5 million rows--using character-based "smart keys." Nah, better to load them into
new tables with indexed 64-bit
surrogate keys first, and issue the join on the server, in
one instance of a DB, don't you think?
Now try doing
diffs (changed data) between two versions of the same DB, where
both are OVER 100 GB . Try working with databases between
100 GB and a terabyte with these tools. And you'll find that
your MySQL falls over and barfs. Even PostGreSQL has a hard time with data this large. Remember, you're posting on Slashdot, repairing manually entered data into 100GB-1TB databases is my full-time job So, sorry, Beliskner YOU are the one talking trash here. The databases you've dealt with are 2-3 orders of magnitude
smaller than what constitutes a "big" database these days.
And offline, not every DB is ODBC compliant--try something based
on PICK or UNIDATA, and no you can't pull each table into one
CSV file, because there are hierarchical data structures -- subtables--defined in them. So one table in unidata, as each field
might be a whole hierarchy of subtables--might require a dozen
or more CSV files. And you'll have to reconstruct
the metadata manually, because metadata is optionally defined by
the programmer in unidata, not information that gets stored
automagically every time you create a table in a real rdbms. This is what legacy
systems are like. For your next exercise, weedhopper, try pulling
the correlate data out of a 1TB DB2 database on an IBM S/390 running MVS using an ODBC join --to the Unidata DB running on an Alpha half way across the country. Can you spell "couriered tapes"? Sure. I knew you could.
Or maybe
you can pull the hundred some-odd tables, over 2 GB each, into
into some flat CSV files onto your FAT file system on your PC with Access. guffaw! don't forget the native encoding is EBCDIC. Don't
forget that you can't even HAVE a >2GB FAT partition, so you'll have
to upgrade to NTFS or a linux/unix file system and OS before you
even get started. Obviously, this isn't the way a pro would go about
it, but you can't imagine the number of business analysts I've seen
try to do things like this, and wonder why it "doesn't work." They
call their desktop help-desk people because "I pushed the '!' button,
and it hung my machine!" They think that the techniques that worked
with their data pre-acquisition or merger will work when the data
are too large to be cut-and-pasted into Excel post-merger. Hours of entertainment watching these guys.
Your challenge is to build something fast enough and reliably enough
that it keeps up with all the
changed data coming through every day in both billing engines, each being updated constantly by a couple hundred
operators each in a dozen different
call centers, each following wildly diverging business
rules regarding the updates, and one of them (unidata) applying piss-poor referential integrity constraints on update. Design, build
and test the process to join these DBs "using ODBC" then get back to me when you're done. mmmKay? See you in a few months.
Don't forget that
"ODBC compliant" means that every driver will have a slightly
different way of interpreting NULL fields, Boolean fields,
64-bit keys and date/time formats. I love guys like
you, because you always underbid on the big jobs and then
fail miserably while going under -- happens every generation,
providing just decades of schadenfreud entertainment. Hint: for a job this big,
you're going to have to dump ODBC altogether, and implement
a comms standard over raw sockets because, besides being functionally
inadequately specified, ODBC slows everything down by at least an
order of magnitude -- which means the difference between a correlation
taking 10 hours or 10 DAYS. If it has to be done EVERY DA
Re:Good thing databases are perfect!
on
Databases and Privacy
·
· Score: 4, Informative
Actually, governments and corporations are very
willing to spend
tremendous amounts of money on:
data cleansing and QA
data warehousing
surrogate key generation
data correlation
data mining
geocoding (linking an address to a lat/lon, identifying the lat/lon with a neighborhood, municipality, county, state, country; linking a lat/lon to an address)
database integration
data migration
legacy systems
data audit trail generation
dataset purchases
It's not "impossible" to reconcile different data on the same
subjects, it's just a whole lot of work, much of it
analysis and data discovery, and being able to do
the work typically
requires that you be familiar with a variety of RDBMS's,
billing engines, debt engines, file formats and platforms.
The combinations are almost endless.
Take heart. You'll start seeing the same
kinds of problems over and over: middle initial vs. middle name,
spacing and capitalisation issues, address data entered as a small
number of big long strings that needs to be parsed out into
attributes, date/time format inconsistencies, record doubling,
data integrity issues (1 supposedly unique key identifying
multiple distinct records), data accuracy issues (data way out
of range, data incorrect), null values with meaning, attributes
used to identify a range of different things, "smart keys" that
are not so smart being used to code everything about a customer
in 8 characters, and so on and so forth. And you'll know to
look for these "usual suspects" first, and develop some standard
ways of dealing with them.
Metadata
management and ETL tools make the job easier, but as you
say, data are imperfect. There are plenty of
legitimate applications--every merger, acquisition and JV
is yet another opportunity for some more mind-numbing, back-breaking,
soul-destroying, spirit-crushing DB work. Oh goody. That's why
they call it "work," I suppose. I'm surprised the work Neo
was doing in The Matrix -- before he found his "calling" so to speak--was something as creative and interesting
as software development. The real grind is the big databases. As you
so aptly point out.
Many industries have, as their primary asset,
data and data only . Banking and insurance are the classic examples.
Companies in these industries are certainly
willing to invest in their most important asset, because just about all the money in the world is in databases.
A database is like a gun. It can protect you, it can kill you.
You can shoot yourself in the foot, somebody else can take you
out in a 'hunting accident.'
The difference between a database and a gun is that a gun
needs someone behind it pulling the trigger. A database, OTOH,
has triggers that can fire based on whatever criteria's been
set--like when a 'David Nelson' tries to fly to Peoria. Yah, it's
scary, all right.
Campbell's thesis is not particularly religious, but rather
that groups of people create similar myths. Campbell, like Jung,
arrives at this conclusion through comparative mythology.
That the same archetypes should emerge in the dominant
storytelling medium of the day--sci fi movies--is not
surprising.
Believe it
or not, Hollywood draws heavily on Joe Campbell,
all the time . Even the fact that Hollywood
stories are so formulaic is evidence of this: there's
always The Hero, The Trickster, The Seductress,
The Higher Power, etc. It's the very familiarity of
these archetypes that make these modern-day myths so
compelling.
Most Hollywood movies, however, stay within the
conventions of the archetypes and their stories, rather than raising
questions about art, artifice, consciousness, myth
and reality. Hollywood movies work within dramatic
and myth-making conventions, whereas The Matrix is
about getting behind and beyond the masks, which is
what is so fascinating about it. The Matrix
chooses Gnostic Christian
forms for its own mask, rather than the forms we're
more familiar with from schul ,
catechism class, Sunday School, etc. The choice
of gnostic forms allows them to get much closer
to eastern philosophies, while dodging doctrinal
disputes. Skillful means, grasshopper.
One thing I was surprised to see undiscussed in
the CSM article was really the central theme of the
Matrix, and also the unifying principle in all
religions: compassion. The AI simulacra, The Smiths,
lack compassion, and his is what makes them, and
the artificial world they have constructed, so inhuman,
so terrifying and so inhumane.
The "is it live, or is it Memorex" debate
is begging the question, really. It duss jusn't
matter. Also, I
wish that they'd used Peter Gabriel's song
Mercy Street just once.
This is the most important paragraph in the article:
The healthiest organizations we encounter do development iteratively and incrementally; testing continuously. They have good configuration management policies. A lot of organizations still don't have this. An astounding number of development teams don't use any configuration management tools. This reflects the fact that a lot of software development teams are going about it in an ad-hoc fashion. That's a problem of process. And until they get their process right no tool you throw at them will add value.
Read that 10 times. I've seen it over and over. Happens all
the time. I didn't know whether to laugh or cry. I wish
he'd mentioned Rational Robot at least once, and the importance
of test harnesses in general. gcc and g++ would never have gotten
where they are today without dejaGNU, for example.
His comments on the mismatch between relational data and OO data
is quite true -- Zope, for example(which is, underneath it
all, an OODBMS) just falls over when you
start loading it up with 10 GB or so, which is why it's
recommended to put an RDB under it for relational data,
and access to a chrooted jailed filesystem for big data
stored as flat files. It would have been reasonable for
him to mention, however, that these issues are addressed
in spades
by tools such as Oracle 9iAS connected to an Oracle 9i DB,
and IBM Websphere connected to a DB2 UDB in the real world.
In terms of functionality, these are are the "enterprise-ready"
tools that sit in the same space as Zope and PostGreSQL.
I was also surprised that, in his discussion of bringing
relational and OO data to the end user he didn't mention
Data Warehousing, OLAP (Online Analytical Processing),
Metadata Management tools, Multidimensional
database technologies, Business Intelligence tools and
such as Cognos, Oracle SQL_OLAP and BI_Beans, Coglin Mills,
Datastage, etc etc etc. But then, it was already 10
pages long, and the .NO^hET Magazine editors might
not have been able to find the space for the balance of that
discussion.
What is the point of jamming them under RICO? Criminalize the forging of headers and leave it at that.
Agreed -- the thing I would be concerned about, in the use of RICO, is
that how many innocent people who are unwittingly running open relays
could get unfairly stung?
Granted, they should be more careful,
but how far can this go? It's simple enough to filter at the SMTP level, and just reject mail that doesn't come from a legitimate domain, or is coming from an IP number that doesn't match the
domain name in the header. But what if the individual packets -- at the IP layer -- are being routed through your network? What if you're, say, running a router for
a multihomed LAN for a rural community--say a wireless or satellite link and a
T1 line -- and do not know that some (but not all) of
the packets associated with a piece of SPAM (or a lot of it) are going into your network and out again -- dynamically routed?
Will "being
careful" be precisely defined to say what packets, and at which network layer, we are
responsible for filtering, and which packets and at which network
layer we cannot, and should not, be held accountable? What if the
address they're forging is one of mine ? Will they seize
my property first, ask questions later?
And what about sending your mail through a series of mail servers
and proxies, i.e. an SMTP server behind your firewall where your
mail is actually handled vs. the firewall that simply proxies the
traffic (and possibly checks for spam!). Will this be misconstrued
by an over-eager law enforcement person who does not know the difference between this careful practice and "forging mail headers." After all, the machine the mail came from originally is not the
same as the one transmitting to the rest of the world.
And good heavens, what about those of us running or using mixmaster for legitimate purposes? ZKS? anonymizer? or even SSH for that matter? If the feds can't actually see what's going on through a wiretap or packet sniff, will they simply assume
this to be evidence of "spamming" from some remote host? Will they
start outlawing the practice of logging into your home sever over
ssh and checking your mail in a text-based mail reader?
And what about UUCP mail, mutt, DECnet and BITNET mail? In theory, your bog standard sendmail.cf can still handle these
headers. Granted, you don't see things like ucbvax!hplabs!hao!joeuser%decvax@mit-lcs.arpa
anymore, but (shudder) what if spammers started exploiting
some of these more bizarre and ancient addressing techniques from
the old store-and-foreward networks, that may still appear to be valid addresses
according to most sendmail.cf files?
--When marriage is outlawed, only outlaws will have in-laws.
You might want to try an open-source relational database engine like PostGreSQL
This means, of course, you'll have to create your own
schemata for logging version control and records added, but
versioning additions to the database -- and user/connect information --
can be tracked with a combination of triggers and timestamps in a
separate table. These are fairly
standard techniques in generating
an audit trail for tracking relational database changes and enforcing data integrity constraints.
While the syntax varies from database engine to database engine--PostGreSQL is a good (free) place to start, and if the
spirit moves you (or if the DB becomes too large) the syntax differences do not preclude your moving to, say, a development edition of IBM's DB2 UDB or even (aack!)
Oracle. All three run rather nicely under SuSE Linux, and are said to run quite nicely under
RedHat, as well.
It probably wouldn't harm you at all to develop this database with
a relational database, and test it under different engines--
in fact, it would likely make you highly employable in the very near
future.
"Pick up the Pieces"
by Average White Band. I have no idea who the person you referenced is.
Randy and Michael Brecker (aka the Brecker Brothers) were the
horn section in AWB--or more accurately, AWB was the Brecker
Brothers' backing band. "Pick up the Pieces" was possibly the only good thing to come out of "The Disco Era", although I used to catch them
on WRVR, which was the jazz station in NY (before it suddenly became
a country station -- without warning! One day, I tuned in
and suddenly it was like Waylon Jennings and friends, featuring such immortal tunes as "Drop Kick Me Jesus, Through The Goalposts of Life". The event
could have been an episode out of Zippy the Pinhead. Bi-zarre...)
A Heartbreaking Work of Staggering Genius
on
Dancing Barefoot
·
· Score: 4, Interesting
From the review of Dancing Barefoot:
The best is Houses -- although it sometimes ranges into maudlin territory, it is also the most courageous writing in the book. Wheaton's generation has been raised on a diet of pop culture and cynicism, and it's invigorating -- if somewhat startling -- to see someone of that generation openly expressing such feelings of devotion and despair.
Startling, but not unique in this generation. David Eggers'
memoir
A Heartbreaking Work of Staggering Genius: Based on a True Story
specialises in this style of self-revealing, self-referential, reflective, intelligent, witty prose. One can't help but notice the similarities in the relationship between Eggers and his brother Toph, and the relationship Wheaton has with his stepson. While
reveling in the part of himself that will always be a boy brought out by the younger (the child is father of the man, and all that) he also can reflect on the call to greater responsibility required by the
relationship, accepted somewhat reluctantly.
Eggers started a whole (and very good)
imprimatur with a
group of authors and artists who also transcend the pop culture they were raised on. Good Stuff and worth reading!
Slashdot Mirror
Your daily requirement for vitamin A more than doubles when you use your eyes for close work every day. Eye strain is a symptom of vitamin A deficiency. Munch on a few carrots and cashews during the day. Get some sunlight for the vitamin D. Cashews have calcium, which improves the absorption of other vitamins. Have a glass of V8. Canteloupe for breakfast. Plenty of fresh, raw fruits and vegetables, and drink water! 8-10 glasses a day. A balanced mineral and vitamin combination regime will take over a month to really show its positive effects, so keep up with the vitamins, and get the extra vitamin A you need with carrots and sunshine.
Also, instead of just inverting your colors, you can go to green-on-black or orange-on-black for text and code. Most relaxing. All the other advice here (looking away from your screen frequently, getting up and walking around every 45 minutes or so, using saline eyedrops and eye wash) is all good stuff.
Some people flaunt the numbers "36-24-36" other fluant "IQ of 160" either way your are stil trying to show off and live through your children.
You can choose what you want. You can even choose to remain ignorant of your own capability for discernment. That's your choice.
I choose to promote girls and womens' education and accomplishments, particularly in science, engineering, software development and mathematics.
I choose to deplore things that cheapen or degrade those accomplishments. One of those things is Aimee Deep's interview, which reveals her self-absorbed attitude, her unprincipled upbringing, and her lack of knowledge of the technology and her misrepresentation as a "geek girl"
A woman using her body as another tool in her arsenal does not neccesarily indicate she is not intelligent. Actually a woman who can and doesn't is actually quite ridiculous.
In the spirit of respectful debate, allow me to offer a different perspective. We may have to agree to disagree, which is fine.
First of all, the topic isn't what you want in a personal relationship. The topic is to what extent a female scientist, engineer, software developer, artist, musician -- professions in which there is a tangible, concrete product to design, create and deliver -- can or should be "using their bodies" to "get ahead".
What does it say about the quality of the product and the intelligence and integrity of the people behind it when your highly experienced, highly trained technical consultant has to literally get her dress up over her head in order to close the sale? " Wow man, that is just soooo lame!" in the parlance of our little friend Aimee. "Simply unprofessional," is how an adult might put it.
If your only criteria for success is how far ahead a person gets or next month's bottom line, then sure, why shouldn't she hand out BJs with the RFCs, RFPs and SLAs. OTOH, if your criterion for success is to build a solid reputation for your profession, for your firm, and for yourself, then what looks "ridiculous" are the cheap and sleazy tactics your competitors will stoop to.
So, while I agree with you that being well-presented or even stunningly beautiful is a terrific asset, being cheap and sleazy is not.
Ask yourself: do you respect aimster/madster more or less for the founder's putting his underaged daughter in a bikini up on his company's website? Sure, it may attract attention in the consumer market, and they may get some short-term mileage out of it.
However, if you were a CIO or one of the Joint Cheifs, would you commission the company behind it --Johnny Deep's -- to develop a military comms system or a corporate procurement system based on the underlying technology they developed with aimster? Would you want miss Aimee directing the project? Hmmm? Probably not.
The technology is there, but Aimee doesn't really understand it. And what's a girl with her level of personal and professional integrity going to do with your classified or proprietary system if someone offers her money for it? What will her price be, if all's it takes is a bit of attention on the internet to get her to take off her clothes? Look at her goals and values. She said it herself: "it's all about ME" Completely self-centered. It's how she was raised, and who raised her.
Look at the quality of aimster's business relationships, and relationships with its employees. In the toilet! Don't you think that has something to do with the kind of people running the company? You know, the same kind of people that would put a picture of their own teenage daughter half-naked up on their website to promote their product.
She can choose to go along with it, or she can choose not to. I would have a lot more respect for her if she at least understood the technology behind aimster's products (she dodged a question about that in the interview). But you,
And the "using her body" bit that you suggest -- let's see if I can find something positive in it. HIV positive, maybe.
On balance, it's unhealthful, it's deplorable and it's unprofessional. Any female scientist, engineer, software developer, artist, mathematician, musician who feels she has to do things like that to "get ahead" is truly, truly pathetic. A real lamer, whether she's any good at what she does or not. If she's good her chosen profession, she shouldn't have to engage in the oldest profession.
I would like to know what the ladies of slashdot think of this Aimee Deep girl.
Well, since you asked...
Being a teenaged girl does NOT let her off the hook. You are a combination of what you do and how you communicate it.
Aimee Deep is clearly just a "scene whore." Big deal. She'll probably grow up to be one of those women "in IT" who've never written a line of code in their lives. Typical.
When I was her age, I:
My neighbor has 2 daughters. The younger has an IQ of 160, and builds and programmes Lego Mindstorms with Linx/esterel, and the older programmes in PERL under linux and is training to be an airplane pilot. They're 12 and 16, respectively.
Its just plain wrong that all of their accomplishments will only subject them to comparison with a stupid girl like Aimee Deep, "yes, maybe she can programme, but how does she look in a bikini."
For crissakes, we train as programmers, airplane pilots, engineers so that our work can be objectively judged on its merits, not on the exposure of our breasts! If we wanted to be judged on our breasts, we would have gone into fields where there are no objective measures beyond "36-24-36".
Touting a stupid girl like Aimee Deep as a "geek girl" creates a situation where women who are highly trained, highly educated, and have decades of technical experience-- get lumped in with the stupid little girls in the line-up. With an undergraduate degree in engineering, a Ph.D in physics and 25 years of professional programming experience, I still have to fight the "oh, look she knows what all these big words mean, maybe she can write our documentation for us, and hey joe, are you getting any off of her, nudge nudge, wink wink" attitude.
Quite frankly, I'm utterly disgusted at Aimee's father's putting her up as a cheesecake scene whore and then trying to claim she's some kind of "geek girl" when she's anything but. The interview only reveals her stupidity.
If she were a brilliant programmer, engineer, pilot, physicist, musician, artist, whatever, and happened to be stunningly beautiful, it would be like, "well... maybe her looks have helped her get ahead, but how is that different than a tall guy with a gorgeous voice and beautiful manners using his personal attributes to help sell his software?" There's lots of good software out there, but something has to work and something has to have been created . This gal claims to be creative , but is she making the music ? No. Is she writing the software? No.Unfortunately, Aimee Deep is pretty ordinary in the looks department, none too bright, and definitely not accomplished in anything useful or creating anything worthwhile. At best, she's a cheerleader for EFF. yawn!
Truly pathetic.
To address the number of devices they'll need, I'd bet on their making the transition to ipv6, which has been, unfortunately, stymied and postponed for years now.
Just demonstrating the transition in a rather large real-world application would be one of the more useful spinoffs. At the very least, it will help keep ipv6 efforts alive.
certain hardware manufacturers utterly refuse to support anything other than Windows
Since you mentioned you did some coding, you may want to check out Linux Device Drivers plus some of their other kernel tweaking/modding books.
Buying a book isn't going to get her the board spec, unfortunately. To get the job done quickly, she'll need the board spec.
Otherwise, she could start by using the generic pci driver to probe the board's parameters in freebsd, or use phob to observe the board's parameters.
This would be an excellent chore for a grad student, as it would provide her with a useful skill while not really interrupting her studies of, e.g. The Effect of Gamma Rays on Man-in-the-Moon Marigolds
yudit is quite nice, as well as the new vim and emacs. An interesting exercise is to run ascii, utf-8, and utf-16 LE and utf-16 BE (little and big endian, respecitvely) representations of the same text (say a 2-line text message) through
% od
and see what's really being stored in them thar files.
There's also a whole bunch of useful tools in the ICU (no, not the Intensive Care Unit!) with links to the openl18n pages. In terms of being extremely informative, from the top-level overview of internationalisation of software down the the greatest technical detail you can actually use -- including a really useful set of software libraries with source code provided , I can't recommend the ICU pages highly enough. Context plus details in context. A revelation.
Interesting how the T in TIA went from "Total" to "Terrorism" in one swell foop. sigh! Oh well.
"T for Texas, T for Tennessee" is from an old Jimmy Rogers song by the same name.
He swaps out said drive, zero down time, and nary a performance hit because a hot spare came online. You have got to love that kind of service and uptime, and just plain reliability.
Yup! AS/400's (aka iSeries) are like the Energizer Bunny.
In the database wars, you have to remember that the chip the AS/400 is based on has been native 64 bit for a long time (great for batch transaction processing on large tables--one place Oracle falls down big-time on any platform) and the instruction set is geared towards RDBs. What do you expect from a company that's been building and processing databases since the turn of the last century -- that's right, Hollerith's cards were used in the 1900 census, which are, BTW, the same size as a 1900's US dollar bill.
IBM learned a lot about databases from developing applications on machines that process enormous stacks of punch-cards mechanically--including searches, sorts and selects based on various criteria. Unfortunately in the German census processing in the 1930's, one of these criteria they sorted, searched and selected on was "who is a Jew?" -- and the IBM punch-cards these data were recorded on were imprinted with swastikas.
I wonder if anybody's looked at the business transactions recorded in cuneiform to see if one could scan down the columns and across the rows visually to detect patterns and anomalies (much in the same way BA's look at long columns of numbers in their spreadsheets). This would be the earliest example of data processing. Tremendous reliability of the physical media, too.
They also propose that all computer systems should have an "undo" feature built in to allow harmful changes (either due to mistakes or malice) to be easily undone...
AS/400's have had this for a long time. Linux does, in the sense that you can load and unload certain device drivers and modules dynamically. But really, in terms of OS architecture and hardware, AS/400's have been way ahead of their time for a long time. Worth studying.Yup. The other way in which Sun's move is similar to SGI's is that the last thing Sun has left that's "special" is JAVA--and the last thing SGI had that was special was OpenGL and VRML.
Very nice stuff, use it all the time-- but neither technologies provide them with anything near the leverage each had in the marketplace when they also had the best hardware and OS to do the job -- enterprise computing in Sun's case, and 3D animation in SGI's case.
Another analogy is that Sun's move to the industry standard X86 architecture is similar to SGI's attempts to move to industry standard NTOS, then Linux. Both were a bust, causing huge code migration issues for companies that had to make the switch away from IRIX. Didn't exactly endear them to thei existing customers.
The whole Sun/SGI story is really the last gasp of the last wave of computing -- workstations and mini-mainframes -- from the 80's. Just as IBM's attempts to get into the workstation space in the 80's was eaten alive by Sun, HP and SGI, and their attempts to get into the mini-mainframe space were eaten alive by DEC.
What IBM had going for it, in terms of survival, was that it was just so darn BIG. The failed attempts to get into the workstation and mini-mainframe space were balanced by spectacular success in the PC space while managing to hold on to the mainframe and midrange enterprise computing space (S390's and AS/400's -- now called what, Zseries and Iseries).
Remember when PCs were called "microcomputers"? IBM coined the term Personal Computer for one of their products, and it stuck like Kleenex to your Hush Puppies.
Yup. That's why you're going to RTFS of the TCPA module provided, and then write your own applications.
These are absolutely terrific articles. Their distribution of an open source TCPA linux module satisfies a lot of concerns and questions many of us had about TCPA in a concrete and specific manner.
One concern still exists: that DRM and Palladium will be used to create a "mainstream" set of M$ applications which give people the illusion of security, while concentrating most of the information and control in the hands of the few.
The most important step people in the open source community can take next are to get a system with a TCPA chip and start developing drivers, firewall systems, proxies and applications that make good solid use of the technology: tsshd, tsquid, tsftp, thttpsd, tbsd, toggd, tnamed, texim, tkonq...
If you've stumbled across evidence of substantial and systematic bilking, theft, fraud, etc. in a corporate database on an utterly massive scale... remember, fish rots from the head down. Going up your chain of command is what you have to do, but do expect severe and immediate retaliation.
Just them knowing that you know what they've been up to, by your routine data QA, is enough to cause sudden complaints about your "behaviour." Remember, it takes two to tango, but only one to squirm . Their complaints are evidence that they're starting to squirm. You need a plan now.
When the going gets tough, the tough take notes . Keep copies of things. You you are going to need a well-planned and pre-established "exit strategy", because you will be punished for doing the right thing.
While "Retaliation for Opposition to An Unlawful Practice" is illegal, it will take you 3-5 years to prosecute your retaliation case, while also giving testimony in the civil and criminal cases the FBI or Serious Fraud Office is going to be bringing against them. You are going to need one heck of a safety net.
So your order of business is:
- Detect Evidence
- Discuss with Spouse, Family, Religious Leaders
- Document Evidence
- Find out whose the best lawyer in the
State, if not the Land for handling your case
- Copy Evidence,place under lock and key
- Find another job, sell excess assets, cash in annuities
- Report Evidence up Chain of Command
- Enjoy Watching them Squirm!
- Resign at the worst possible time for them
- Provide Your Evidence to The Authorities
- Going to the Press is a last resort
You have to discuss this with your spouse and grown children as soon as you even have suspicions, so that you can plan your exit strategy together. They have to understand that you all might be a lot happier in the Peace Corps or setting up wireless networks in Africa, or living on a high-school teachers' salary or grad student stipend. If you belong to a church, mosque or synagogue, discuss it with your pastor, priest, imam, rabbi-- because, God help you, you will need serious moral support when the poo hits the ventillation system.When you must report criminal wrongdoing expect to get canned--for "other reasons" of course. You will be surprised at how lame a case they'll be willing to make for those "other reasons." So will the judge.
Child pornography is criminal wrongdoing. Bilking legitimate shareholders of millions of dollars a month is criminal wrongdoing. A utility defrauding half a nation to the point that its factories are closing, its schools are cold and dark, and its hospitals have to turn away sick children is criminal wrongdoing.
And this is just bog standard corporate IT after a merger or acquisition, because one of the reasons companies underperform (making them ripe for a buy-out) is that their legacy systems are such outdated poorly implemented crap. Rarely are the compatibility or modernity of the production systems adequately addressed in the course of due diligence prior to the merger or acquisition, and this is where they suddenly find they're getting bit in the arse post-merger, or post-acquisition. Hence the big bucks for the DB people, because every day of down-time would cost them a lot more than your fee is to sort things out for them.
And yes, parsing addresses can be as simple as you say. Until you get to international addresses that put the street address, city and country in a different order. And the postal codes suddenly have characters in them, and the variable length indicates varying degrees of specificity in the addressing (as in the UK). And the alphabetisation will not follow the same ordering as ASCII or EBCDIC encoding, so you need to dub them all into UNICODE and applying the UCA (Unicode Collation Algorithm) to get them to come out in the alphabetical order correct for the customer's country. What about when the result set needs to be alphabetized in an order which is correct for several different languages at the same time? And which transliteration are you going to use for Thai vs. Arabic? Which address parser you going to use for geolocating banking customers in the Phillipines and Colombia when most of the customers have not given their addresses to their banker--for personal security reasons?
But, yes, in the simpler cases, you do develop some fairly standard ways of solving the standard problems posed by the original commenter. That was one of my points, you might have noticed. Thank you for supporting it with a simple example.
Oh, and by the way, Beliskner, you've contradicted yourself in two paragraphs. In one, you say that it's your full-time job to repair data, and in the last line, you imply that it's not. I suspect the truth is the latter.
Try using ODBC on joins between three tables, one with 57 million rows another with 200 million rows and a third with 1.5 million rows--using character-based "smart keys." Nah, better to load them into new tables with indexed 64-bit surrogate keys first, and issue the join on the server, in one instance of a DB, don't you think?
Now try doing diffs (changed data) between two versions of the same DB, where both are OVER 100 GB . Try working with databases between 100 GB and a terabyte with these tools. And you'll find that your MySQL falls over and barfs. Even PostGreSQL has a hard time with data this large. Remember, you're posting on Slashdot, repairing manually entered data into 100GB-1TB databases is my full-time job So, sorry, Beliskner YOU are the one talking trash here. The databases you've dealt with are 2-3 orders of magnitude smaller than what constitutes a "big" database these days.
And offline, not every DB is ODBC compliant--try something based on PICK or UNIDATA, and no you can't pull each table into one CSV file, because there are hierarchical data structures -- subtables--defined in them. So one table in unidata, as each field might be a whole hierarchy of subtables--might require a dozen or more CSV files. And you'll have to reconstruct the metadata manually, because metadata is optionally defined by the programmer in unidata, not information that gets stored automagically every time you create a table in a real rdbms. This is what legacy systems are like. For your next exercise, weedhopper, try pulling the correlate data out of a 1TB DB2 database on an IBM S/390 running MVS using an ODBC join --to the Unidata DB running on an Alpha half way across the country. Can you spell "couriered tapes"? Sure. I knew you could.
Or maybe you can pull the hundred some-odd tables, over 2 GB each, into into some flat CSV files onto your FAT file system on your PC with Access. guffaw! don't forget the native encoding is EBCDIC. Don't forget that you can't even HAVE a >2GB FAT partition, so you'll have to upgrade to NTFS or a linux/unix file system and OS before you even get started. Obviously, this isn't the way a pro would go about it, but you can't imagine the number of business analysts I've seen try to do things like this, and wonder why it "doesn't work." They call their desktop help-desk people because "I pushed the '!' button, and it hung my machine!" They think that the techniques that worked with their data pre-acquisition or merger will work when the data are too large to be cut-and-pasted into Excel post-merger. Hours of entertainment watching these guys.
Your challenge is to build something fast enough and reliably enough that it keeps up with all the changed data coming through every day in both billing engines, each being updated constantly by a couple hundred operators each in a dozen different call centers, each following wildly diverging business rules regarding the updates, and one of them (unidata) applying piss-poor referential integrity constraints on update. Design, build and test the process to join these DBs "using ODBC" then get back to me when you're done. mmmKay? See you in a few months.
Don't forget that "ODBC compliant" means that every driver will have a slightly different way of interpreting NULL fields, Boolean fields, 64-bit keys and date/time formats. I love guys like you, because you always underbid on the big jobs and then fail miserably while going under -- happens every generation, providing just decades of schadenfreud entertainment. Hint: for a job this big, you're going to have to dump ODBC altogether, and implement a comms standard over raw sockets because, besides being functionally inadequately specified, ODBC slows everything down by at least an order of magnitude -- which means the difference between a correlation taking 10 hours or 10 DAYS. If it has to be done EVERY DA
Actually, governments and corporations are very willing to spend tremendous amounts of money on:
- data cleansing and QA
- data warehousing
- surrogate key generation
- data correlation
- data mining
- geocoding (linking an address to a lat/lon, identifying the lat/lon with a neighborhood, municipality, county, state, country; linking a lat/lon to an address)
- database integration
- data migration
- legacy systems
- data audit trail generation
- dataset purchases
It's not "impossible" to reconcile different data on the same subjects, it's just a whole lot of work, much of it analysis and data discovery, and being able to do the work typically requires that you be familiar with a variety of RDBMS's, billing engines, debt engines, file formats and platforms. The combinations are almost endless.Take heart. You'll start seeing the same kinds of problems over and over: middle initial vs. middle name, spacing and capitalisation issues, address data entered as a small number of big long strings that needs to be parsed out into attributes, date/time format inconsistencies, record doubling, data integrity issues (1 supposedly unique key identifying multiple distinct records), data accuracy issues (data way out of range, data incorrect), null values with meaning, attributes used to identify a range of different things, "smart keys" that are not so smart being used to code everything about a customer in 8 characters, and so on and so forth. And you'll know to look for these "usual suspects" first, and develop some standard ways of dealing with them.
Metadata management and ETL tools make the job easier, but as you say, data are imperfect. There are plenty of legitimate applications--every merger, acquisition and JV is yet another opportunity for some more mind-numbing, back-breaking, soul-destroying, spirit-crushing DB work. Oh goody. That's why they call it "work," I suppose. I'm surprised the work Neo was doing in The Matrix -- before he found his "calling" so to speak--was something as creative and interesting as software development. The real grind is the big databases. As you so aptly point out.
Many industries have, as their primary asset, data and data only . Banking and insurance are the classic examples. Companies in these industries are certainly willing to invest in their most important asset, because just about all the money in the world is in databases.
A database is like a gun. It can protect you, it can kill you. You can shoot yourself in the foot, somebody else can take you out in a 'hunting accident.'
The difference between a database and a gun is that a gun needs someone behind it pulling the trigger. A database, OTOH, has triggers that can fire based on whatever criteria's been set--like when a 'David Nelson' tries to fly to Peoria. Yah, it's scary, all right.
if you win the lottery, who the fuck cares about school? I'd quit that day.
Oh, well there's an enlightened point of view. Perhaps you'd like to conduct a seminar on that topic. I'm sure you'll be invited to.
Campbell's thesis is not particularly religious, but rather that groups of people create similar myths. Campbell, like Jung, arrives at this conclusion through comparative mythology.
That the same archetypes should emerge in the dominant storytelling medium of the day--sci fi movies--is not surprising. Believe it or not, Hollywood draws heavily on Joe Campbell, all the time . Even the fact that Hollywood stories are so formulaic is evidence of this: there's always The Hero, The Trickster, The Seductress, The Higher Power, etc. It's the very familiarity of these archetypes that make these modern-day myths so compelling.
Most Hollywood movies, however, stay within the conventions of the archetypes and their stories, rather than raising questions about art, artifice, consciousness, myth and reality. Hollywood movies work within dramatic and myth-making conventions, whereas The Matrix is about getting behind and beyond the masks, which is what is so fascinating about it. The Matrix chooses Gnostic Christian forms for its own mask, rather than the forms we're more familiar with from schul , catechism class, Sunday School, etc. The choice of gnostic forms allows them to get much closer to eastern philosophies, while dodging doctrinal disputes. Skillful means, grasshopper.
One thing I was surprised to see undiscussed in the CSM article was really the central theme of the Matrix, and also the unifying principle in all religions: compassion. The AI simulacra, The Smiths, lack compassion, and his is what makes them, and the artificial world they have constructed, so inhuman, so terrifying and so inhumane.
The "is it live, or is it Memorex" debate is begging the question, really. It duss jusn't matter. Also, I wish that they'd used Peter Gabriel's song Mercy Street just once.
This is the most important paragraph in the article:
The healthiest organizations we encounter do development iteratively and incrementally; testing continuously. They have good configuration management policies. A lot of organizations still don't have this. An astounding number of development teams don't use any configuration management tools. This reflects the fact that a lot of software development teams are going about it in an ad-hoc fashion. That's a problem of process. And until they get their process right no tool you throw at them will add value.
Read that 10 times. I've seen it over and over. Happens all the time. I didn't know whether to laugh or cry. I wish he'd mentioned Rational Robot at least once, and the importance of test harnesses in general. gcc and g++ would never have gotten where they are today without dejaGNU, for example.
His comments on the mismatch between relational data and OO data is quite true -- Zope, for example(which is, underneath it all, an OODBMS) just falls over when you start loading it up with 10 GB or so, which is why it's recommended to put an RDB under it for relational data, and access to a chrooted jailed filesystem for big data stored as flat files. It would have been reasonable for him to mention, however, that these issues are addressed in spades by tools such as Oracle 9iAS connected to an Oracle 9i DB, and IBM Websphere connected to a DB2 UDB in the real world. In terms of functionality, these are are the "enterprise-ready" tools that sit in the same space as Zope and PostGreSQL.
I was also surprised that, in his discussion of bringing relational and OO data to the end user he didn't mention Data Warehousing, OLAP (Online Analytical Processing), Metadata Management tools, Multidimensional database technologies, Business Intelligence tools and such as Cognos, Oracle SQL_OLAP and BI_Beans, Coglin Mills, Datastage, etc etc etc. But then, it was already 10 pages long, and the .NO^hET Magazine editors might
not have been able to find the space for the balance of that
discussion.
What is the point of jamming them under RICO? Criminalize the forging of headers and leave it at that.
Agreed -- the thing I would be concerned about, in the use of RICO, is that how many innocent people who are unwittingly running open relays could get unfairly stung?
Granted, they should be more careful, but how far can this go? It's simple enough to filter at the SMTP level, and just reject mail that doesn't come from a legitimate domain, or is coming from an IP number that doesn't match the domain name in the header. But what if the individual packets -- at the IP layer -- are being routed through your network? What if you're, say, running a router for a multihomed LAN for a rural community--say a wireless or satellite link and a T1 line -- and do not know that some (but not all) of the packets associated with a piece of SPAM (or a lot of it) are going into your network and out again -- dynamically routed?
Will "being careful" be precisely defined to say what packets, and at which network layer, we are responsible for filtering, and which packets and at which network layer we cannot, and should not, be held accountable? What if the address they're forging is one of mine ? Will they seize my property first, ask questions later?
And what about sending your mail through a series of mail servers and proxies, i.e. an SMTP server behind your firewall where your mail is actually handled vs. the firewall that simply proxies the traffic (and possibly checks for spam!). Will this be misconstrued by an over-eager law enforcement person who does not know the difference between this careful practice and "forging mail headers." After all, the machine the mail came from originally is not the same as the one transmitting to the rest of the world.
And good heavens, what about those of us running or using mixmaster for legitimate purposes? ZKS? anonymizer? or even SSH for that matter? If the feds can't actually see what's going on through a wiretap or packet sniff, will they simply assume this to be evidence of "spamming" from some remote host? Will they start outlawing the practice of logging into your home sever over ssh and checking your mail in a text-based mail reader?
And what about UUCP mail, mutt, DECnet and BITNET mail? In theory, your bog standard sendmail.cf can still handle these headers. Granted, you don't see things like ucbvax!hplabs!hao!joeuser%decvax@mit-lcs.arpa anymore, but (shudder) what if spammers started exploiting some of these more bizarre and ancient addressing techniques from the old store-and-foreward networks, that may still appear to be valid addresses according to most sendmail.cf files?
--When marriage is outlawed, only outlaws will have in-laws.
You might want to try an open-source relational database engine like PostGreSQL
This means, of course, you'll have to create your own schemata for logging version control and records added, but versioning additions to the database -- and user/connect information -- can be tracked with a combination of triggers and timestamps in a separate table. These are fairly standard techniques in generating an audit trail for tracking relational database changes and enforcing data integrity constraints. While the syntax varies from database engine to database engine--PostGreSQL is a good (free) place to start, and if the spirit moves you (or if the DB becomes too large) the syntax differences do not preclude your moving to, say, a development edition of IBM's DB2 UDB or even (aack!) Oracle. All three run rather nicely under SuSE Linux, and are said to run quite nicely under RedHat, as well.
It probably wouldn't harm you at all to develop this database with a relational database, and test it under different engines-- in fact, it would likely make you highly employable in the very near future.
"Pick up the Pieces" by Average White Band. I have no idea who the person you referenced is.
Randy and Michael Brecker (aka the Brecker Brothers) were the horn section in AWB--or more accurately, AWB was the Brecker Brothers' backing band. "Pick up the Pieces" was possibly the only good thing to come out of "The Disco Era", although I used to catch them on WRVR, which was the jazz station in NY (before it suddenly became a country station -- without warning! One day, I tuned in and suddenly it was like Waylon Jennings and friends, featuring such immortal tunes as "Drop Kick Me Jesus, Through The Goalposts of Life". The event could have been an episode out of Zippy the Pinhead. Bi-zarre...)
From the review of Dancing Barefoot:
The best is Houses -- although it sometimes ranges into maudlin territory, it is also the most courageous writing in the book. Wheaton's generation has been raised on a diet of pop culture and cynicism, and it's invigorating -- if somewhat startling -- to see someone of that generation openly expressing such feelings of devotion and despair.
Startling, but not unique in this generation. David Eggers' memoir A Heartbreaking Work of Staggering Genius: Based on a True Story specialises in this style of self-revealing, self-referential, reflective, intelligent, witty prose. One can't help but notice the similarities in the relationship between Eggers and his brother Toph, and the relationship Wheaton has with his stepson. While reveling in the part of himself that will always be a boy brought out by the younger (the child is father of the man, and all that) he also can reflect on the call to greater responsibility required by the relationship, accepted somewhat reluctantly.
Eggers started a whole (and very good) imprimatur with a group of authors and artists who also transcend the pop culture they were raised on. Good Stuff and worth reading!