Whatever the future brings, Moore's law is driving the growth of IT.
I respectfully disagree. Without a doubt, it
did provide some inflation for the bubble of
the 90's. But in the long run we have to deliver
value for the dollar, not just lots of cheap
computers which suck down user and IT staff time.
Things seem to be heating back up in the Metro DC area. Following 9-11 things really started moving downhill fast
From my view, things got bad in early 2001
in general in DC. (And they had gone bad
up and down the east coast in mid-2000 for
the manufacturing sector that I used to work
in.) They are turning upwards; the
various on-line job site (like DC.Techies.Com) are
now consistently turning up a dozen or two jobs
consistent with my profile every week, a big boost over
what it was a year ago.
It will inevitably recover because IT is
too important. It will expand because IT has definitely not met the limits of what it can do.
That's a pretty twisted attitude to take. Yes,
we do more with computers than we did ten or
twenty years ago, but are we really doing it
any more efficiently? IT staffing and spending
had ballooned by a factor of 100 over twenty
years; are we really delivering that much more
value? Computers are thousands of times more
powerful than they were twenty years ago; do
we really need more computers than we did back
then?
Armies of IT workers to run around and reboot
machines continually is *not* progress. Unfortunately in many organizations the "strength" of an IT department is measured by the number of
IT staffers - and not by the value actually delivered.
Absolutely. It has to be. But that doesn't
automatically make Oracle king:-). We were
pushing data around for a long time before Oracle
(or any other relational database) came along.
Storing data in flat files in not conducive to doing complex analysis or reasearch against. This is the primary reason in
my experience that a working flat file system has been moved into a relational database.
I agree with you - you may always decide, at
some time in the future, to access the data
in a different way. Then just being able to
write a SQL statement, rather than a custom program, is a big win.
But for the vast majority of "turnkey" systems
the data is very simple and/or is always accessed
in the same way every time. In these cases,
Oracle (and the attendants needed to keep the
Oracle database running smoothly) is complete overkill. Something like Berkeley DB
will probably be more important. See
the "Do you need Berkeley DB" page for
a very brief introduction as to when you really
do need a relational DB (which in my opinion is
really a very small fraction of the time) and when
you do not need a full relational DB (which in
my experience is the vast majority of the time).
Fifteen or twenty-five years ago there was an
often repeated mantra:
Nobody ever got fired for buying IBM
The slightly more modern version of this -
Nobody ever got fired for buying Oracle
has now been documented to be wrong!
And this is a Good Thing.
I've got nothing against relational databases
where they have their uses; but in the past
ten years every application
has been converted to requiring a relational
database. I personally know of several cases
where the data - which used to be managed
on an old PDP-11 or the original IBM PC in under
a megabyte of disk space - has been migrated to
Oracle, at enormous cost and expense. Things
that used to be simple (e.g. a list of a few
hundred customers) now require a team of
Oracle database experts and extensive optimization
just to keep up with the same performance that
was achieved on twenty-year-old hardware without
Oracle.
There's even an official designation for a
misused and missaplied technology like this:
Golden Hammer.
Most of the questions you need to be asking at
this point (especially "how do I boot a PC
over the network?") are answered in
this section of the Diskless-HOWTO. It
discusses TFTP, BOOTP, and network boot ROM's.
I understand your desire to quantify the hardware needs for
moving to a centralized system. But IMHO there
are many bigger questions that have to be
answered first:
Policy - Exactly what is being centralized and what isn't? Are browsers going to be run on the central machine and displayed on X-terms? Or are they
going to run on the satellite machines? You have
to answer (or guess the answer) to this question for
each and every application you may have. And
the answers will not only determine the server
CPU/storage architecture, it will also be
vitally important to the network infrastructure.
Development - What sort of
development environment will there be? Will
all software - from the littlest
dinkiest shell script up to the giant mega-app
be forced under CVS? Will you allow "checkout"
to remote nodes, or only on the central node? etc.
All that said, as for remote CPU utilitization
the ruptime command is a start.
Sure, someone might be able to code a
solution in the given time, but does it encourage careful thinking?
A good chunk of programming is being familiar
with common idioms for algorithms, patterns,
and data structures. Combining these common
idioms is mostly what we do when we design and
code a program. The more adept we are at choosing
appropriate structures, patterns, and algorithms,
the better we are as programmers.
Yes, sometimes we really do have to invent
entirely new algorithms. But 99.9% of the time
a good programmer is simply identifying well-known
algorithms and patterns and applying them.
Someone who is always
reinventing the wheel is not a contender.
So I'm not worried that the competition
encourages speed.
Distributing software but not knowledge = problem
on
Linux Tuning Tricks?
·
· Score: 4, Insightful
While Redhat is pretty good at making a
distribution that boots and installs on a
very wide number of machines, it's not
so good at making this distribution be
high-performance. Many things are set to
the safest possible value (like the OP's
IDE DMA modes) when a much more reasonable
value would work on 99% of the hardware out there.
Life is made more difficult because there is
buggy and/or broken hardware out there. I
don't blame Redhat for accomodating this hardware,
but by doing so they are making their distribution
more complicated and less useful for those
"in the know".
To actually learn a lot about Linux and all
the associated tools that make it work, I highly
recommend the Linux From
Scratch method: build everything from source!
You can optimize the build to your machine
and end up with not only better performance, but
a vastly superior knowledge of everything that
used to be "under the hood".
I have to say that I find many of Bruce
Sterling's projects and thoughts fascinating.
That said, the groups that form around him
tend to be the folk who are much more interested
in talking about the problems, rather than
doing anything about it.
Case in point (and very close to my heart):
The Dead
Media Project. I'm in the business of
recovering data from old media, and work with the
media, its users, and associated machines
every day. Bruce's group, however,
seems much more interested in talking about the
issues rather than doing anything about them.
It's my impression that
many Slashdotters are do-ers rather than
talk-ers, and I'm just warning them that there's
very little "do-ing" hapenning in Bruce Sterling's
circle. That said, maybe there should be
more talking going on - but it really doesn't
fit my personal style, and either frustrates
or infuriates me depending on the issue.
fewer than half of Americans with computers say they fully understand how to operate them and all their features
I'm impressed. I spend a couple hours each
workday and a few weeks a year keeping up on
80x86 architecture developments and PCI and AGP
bus features. Yet nearly half of the general
public already knows this stuff inside out!
For the humor-impaired, what I wrote above
was mainly to illustrate how "tech-savvy"
is drastically different depending on who you
talk to. For most folks I suspect that
it means that they know to click "Start" on the
windows menubar to "shut down".
And I work for a railroad that moves a
half-million people a day. I like to think
they're not too dissimilar industries - when
my computers shut down, the railroad stops running. I'm guessing that when your
computer stops, the ship stops moving. That
it doesn't sink or explode (i.e. there are
hardware items that relieve excess pressure, etc.)
There are some differences. My trains have
low-level hardware (based around gobs of
vital relays) that will
stop them from running into each other. I doubt
ships have anything like this.
The standards for what you or I do are
drastically different from what someone
writing software for an airplane's fly-by-wire
system has to do. There, if the computer
stops or starts doing the wrong thing, it
falls out of the sky. Scary stuff.
So, it depends on what the computer controls,
but you haven't given us this information.
If you drill down a bit you find this
letter from a programmer that complains about Open Source.
The most paradoxical comment within this letter
is this:
The RIAA wants its intellectual property (music) to be protected.
Authors want their books protected. I want my industry's intellectual
property to be likewise protected. Is this too much to ask?
In other words, he think that the way to
protect his intellectual
property is to ask that it be illegal for
others to give away their
intellectual property. And this isn't
too much to ask. Scary thought.
He also seems to give the RIAA implicit control
over all music, but that's another flame war.
It's trivially easy to inject false information
via the 'net and have it taken as gospel by
folks who ought to know better (e.g. Slashdot
editors - look at some of the crap that makes
the home page, Wall Street investors - look
at what a teenager with an AOL account can
do with a "fake" press report, etc.)
I'm not saying that Open Source Intelligence is
a bad thing; just that the gullibility index of
interpreters will be a major fact into how
useful it becomes.
You're going along the right path: following
what you're interested in. That's wonderful.
I'm sure you find it challenging and interesting.
But you're just a high-school student. I
don't mean to belittle you with that, but
to devote your career to academics at this point
is a bit early. Certainly, get your degree in
math if that's what you love. Go to grad school
in math and then you'll start to get the flavor
of what life is like in academics. You'll
also (hopefully) learn about the job market there.
Yes, you probably can stay in academics
all your life. You might not like it,
though. You might have to do research in areas
you aren't interested in; for part of your career
you might have very little time to do anything
but teach (while at the same time you really
also have to be publishing!). You'll almost
certainly be looking at moving around a lot,
first to grad school, then to a series of
postdocs at different institutions, then start
moving up the ranks towards tenure (which often
involves moving sideways to other institutions,
too.) If you love travel and not settling down,
it's great. If you're looking for stability, it
may not be for you.
You'll also be able to go into many
industries or branch out into some
other area. Mathematicians are in demand in
a number of different areas (some of which you
may not enjoy, though.)
Don't box yourself in at this point. In fact, it's hard to box yourself in until grad school. So do what
you enjoy, discover new things, have fun!
They'll have a tough time collecting this
tax on mail orders made from out-of-state
retailers.
Right now, of course, those mail-ordering
from out-of-state retailers are supposed
to
remit the sales tax by filing all the paperwork
and sending a check to the state. But individuals rarely
(if ever?) do this. Many businesses (who are
supposed to be doing this on any expense) don't
do this either, though they get caught at it
fairly often by state income tax audits.
California actually is pretty good at finding
out-of-state car buys and collecting tax on them,
but the paperwork involved with registering a
car makes sure these get put in the system. Are
we gonna have to register our CRT's with the DMV?
Now that anti-hydrogen is so easily made, I
just have to wait until they make anti-oxygen
too. Combine them to make anti-H2O, and when
I drink it it'll make thirsty...
PA is a "two-party" state. To me, that means that the girl (or parent/guardian) would be theoretically subject to separate
prosecution (a la Linda Tripp) for giving up the messages (if they are indeed considered to be the same as recording a
phone converstaion, which I find doubtful) but they should still be admissible in this case.
This is just plain wrong. Does this mean
the teenage girl is a criminal for having gone
to the authorities?
This is the same thing that suppressed some evidence in the clinton scandal, the tape recordings of monica talking about
her affair weren't admissable (and got ugly whats-her-face in trouble)
This situation doesn't make sense to me. In
the Clinton-Monica case, Monica wasn't a victim
(at least not in any normal sense of the word.)
In the Pennsylvania case, the victim went to the
police after getting requests for sex from the
perp. Am I being told that the victim wasn't
allowed to do this (and, as an extension, because
the victim didn't get the perp's permission first,
that she's now a criminal for having gone to
the police?)
Many folks seem to be confusing the
TWACS technology
with high-speed Internet access.
There's very little in common. TWACS works by
doing phase-shift modulation on the 60Hz carrier;
this is a wonderfully robust method when implemented correctly, but at best you get a
bandwidth of a few tens of bits per
second. This is great for reading
power meters (where a few bits per
hour is plenty of bandwidth) but
it has nothing to do with high-speed internet
connections.
This morning, I spoke for an hour
with Laura Creighton, who wrote
the device driver for the
equipment between the monkeys
and the computer.
This incident happened at the
University of Toronto in late
November of 1979 or 1980. The
zoology department had used
digital-to-analog and
analog-to-digital converters in a
large number of experiments,
including attempting to synthesize
pheromones to reduce breeding of
beetles that fed on tobacco crops,
some rat neurological
experiments, and some cricket
behavior/population studies. The
rat experiments involved
implanting electrodes in the rats'
brains, and the rats experienced
some pain. The Humane Society
learned of this and raised
complaints, resulting in the
shutting down of the zoology
department for a day while the
experiment was stopped. The
University of Toronto has the
third or fourth most respected
zoology department in the world
and wanted to maintain that
prestige, so there was lots of
screaming to avoid having such a
thing happening again.
The various data from the
experiments was collected by
PDP-11/05 front ends and sent to
an 11/44. Laura Creighton had
written the software for this,
fixing a problem they had
previously with the 11/44 not
being fast enough to collect the
data by itself. This was being
done for 16 to 18 experiments.
The folks in the physiology
section of the Department of
Medicine (separate from Science,
which contained the zoology
department) had bought their first
VAX, an 11/780, and wanted a
similar set-up. So Laura
Creighton and the zoology
department agreed to set up their
software for this. The physiology
people decided not to use 11/05s
in between, since the VAX was
fast enough to handle the data. So
five monkeys were fitted with
caps intended to sense brain
waves, and the caps were attached
to various A-to-D and D-to-A
converters (which were US Army
surplus from 1956) which were in
turn connected to the VAX. This
connection was piggybacked on a
disk drive (pre-RL02), which
contained a disk and was mounted
read-only - the read-only button
was pressed and taped over with a
warning not to remove it. In
normal operation, software would
read data from that drive and
write it to a regular disk. The
room containing the monkeys was
several stories removed from the
computer room.
After some time, the VAX
crashed. It was on a service
contract, and Digital was called.
Laura Creighton was not called
although she was on the short list
of people who were supposed to
be called in case of problem. The
Digital Field Service engineer
came in, removed the disk from
the drive, figured it was then okay
to remove the tape and make the
drive writeable, and proceeded to
put a scratch disk into the drive
and run diagnostics which wrote
to that drive.
Well, diagnostics for disk drives
are designed to shake up the
equipment. But monkey brains are
not designed to handle the
electrical signals they received.
You can imagine the convulsions
that resulted. Two of the monkeys
were stunned, and three died. The
Digital engineer needed to be
calmed down; he was going to call
the Humane Society. This became
known as the Great Dead Monkey
Project, and it leads of course to
the aphorism I use as my motto:
You should not conduct tests
while valuable monkeys are
connected, so "Always mount a
scratch monkey."
Laura Creighton points out that
although this is told as a
gruesomely amusing story, three
monkeys did lose their lives, and
there are lessons to be learned in
treatment of animals and risk
management. Particularly, the
sign on the disk drive should have
explained why the drive should
never have been enabled for write
access.
Fuji M2388, Kennedy Data units, etc. Of course,
when your drive platters are 14" and the head
arms are nearly a foot long it's a lot more
impressive - not much purpose for doing this on
a dinky 5.25" drive!
It's not that cable is underpriced, it's that a T1 is way way way over priced.
As is a T3, and OC3, and everything else by
your standards. (Actually the cost/Mbps
for an OC3 can be discounted substantially over
a single T1.)
You don't seem to grasp the fact that
the cable ISP *is* paying for a couple T1's
or a T3.
Or, at least I hope they
are. If their plan is to get their
connectivity by a long piece of coax running
to the provider in the next town and paying
$50/month, that would explain the service
level that many cable customers are seeing:-)
So the basic answer is: I don't know how much traffic I've used. And I've got a fair idea what I'm doing.
I've gotten even less idea what you're doing,
but MRTG
can track traffic usage for an amazingly wide
number of network (and non-network!) interfaces.
If your interface supports SNMP it's automatic; if it doesn't, there is probably some way of
dealing with it.
Check out my
network usage for an example - integrate
the area under the curve and you have net
hourly/daily/weekly/monthly/yearly usage, and you
can look at the peaks to determine peak (5-min
avg) usage. It even
keeps track of that machine's CPU temperature and fan speed.
Slashdot Mirror
I respectfully disagree. Without a doubt, it did provide some inflation for the bubble of the 90's. But in the long run we have to deliver value for the dollar, not just lots of cheap computers which suck down user and IT staff time.
From my view, things got bad in early 2001 in general in DC. (And they had gone bad up and down the east coast in mid-2000 for the manufacturing sector that I used to work in.) They are turning upwards; the various on-line job site (like DC.Techies.Com) are now consistently turning up a dozen or two jobs consistent with my profile every week, a big boost over what it was a year ago.
That's a pretty twisted attitude to take. Yes, we do more with computers than we did ten or twenty years ago, but are we really doing it any more efficiently? IT staffing and spending had ballooned by a factor of 100 over twenty years; are we really delivering that much more value? Computers are thousands of times more powerful than they were twenty years ago; do we really need more computers than we did back then?
Armies of IT workers to run around and reboot machines continually is *not* progress. Unfortunately in many organizations the "strength" of an IT department is measured by the number of IT staffers - and not by the value actually delivered.
Absolutely. It has to be. But that doesn't automatically make Oracle king :-). We were
pushing data around for a long time before Oracle
(or any other relational database) came along.
Storing data in flat files in not conducive to doing complex analysis or reasearch against. This is the primary reason in my experience that a working flat file system has been moved into a relational database.
I agree with you - you may always decide, at some time in the future, to access the data in a different way. Then just being able to write a SQL statement, rather than a custom program, is a big win.
But for the vast majority of "turnkey" systems the data is very simple and/or is always accessed in the same way every time. In these cases, Oracle (and the attendants needed to keep the Oracle database running smoothly) is complete overkill. Something like Berkeley DB will probably be more important. See the "Do you need Berkeley DB" page for a very brief introduction as to when you really do need a relational DB (which in my opinion is really a very small fraction of the time) and when you do not need a full relational DB (which in my experience is the vast majority of the time).
And this is a Good Thing. I've got nothing against relational databases where they have their uses; but in the past ten years every application has been converted to requiring a relational database. I personally know of several cases where the data - which used to be managed on an old PDP-11 or the original IBM PC in under a megabyte of disk space - has been migrated to Oracle, at enormous cost and expense. Things that used to be simple (e.g. a list of a few hundred customers) now require a team of Oracle database experts and extensive optimization just to keep up with the same performance that was achieved on twenty-year-old hardware without Oracle.
There's even an official designation for a misused and missaplied technology like this: Golden Hammer.
Most of the questions you need to be asking at this point (especially "how do I boot a PC over the network?") are answered in this section of the Diskless-HOWTO. It discusses TFTP, BOOTP, and network boot ROM's.
Typewriters? Would you trust your valuable data to a typewriter company?
Actually, before 1873 Remington was (surprise, surprise) a gun company.
Time to bring back the How to shoot yourself in the foot with [insert-OS-here] thread? :-)
All that said, as for remote CPU utilitization the ruptime command is a start.
A good chunk of programming is being familiar with common idioms for algorithms, patterns, and data structures. Combining these common idioms is mostly what we do when we design and code a program. The more adept we are at choosing appropriate structures, patterns, and algorithms, the better we are as programmers.
Yes, sometimes we really do have to invent entirely new algorithms. But 99.9% of the time a good programmer is simply identifying well-known algorithms and patterns and applying them. Someone who is always reinventing the wheel is not a contender.
So I'm not worried that the competition encourages speed.
Life is made more difficult because there is buggy and/or broken hardware out there. I don't blame Redhat for accomodating this hardware, but by doing so they are making their distribution more complicated and less useful for those "in the know".
Redhat also, of course, distributes the non-kernel binaries optimized for Intel 80386 CPU's when the vast vast majority of installs are going on Pentium-class or better machines. And it doesn't help any that Redhat is using and distributing a very nonstandard version of GCC; see what the GCC developers say about such branches and what application developers say about this branch.
To actually learn a lot about Linux and all the associated tools that make it work, I highly recommend the Linux From Scratch method: build everything from source! You can optimize the build to your machine and end up with not only better performance, but a vastly superior knowledge of everything that used to be "under the hood".
Case in point (and very close to my heart): The Dead Media Project. I'm in the business of recovering data from old media, and work with the media, its users, and associated machines every day. Bruce's group, however, seems much more interested in talking about the issues rather than doing anything about them.
It's my impression that many Slashdotters are do-ers rather than talk-ers, and I'm just warning them that there's very little "do-ing" hapenning in Bruce Sterling's circle. That said, maybe there should be more talking going on - but it really doesn't fit my personal style, and either frustrates or infuriates me depending on the issue.
I'm impressed. I spend a couple hours each workday and a few weeks a year keeping up on 80x86 architecture developments and PCI and AGP bus features. Yet nearly half of the general public already knows this stuff inside out!
For the humor-impaired, what I wrote above was mainly to illustrate how "tech-savvy" is drastically different depending on who you talk to. For most folks I suspect that it means that they know to click "Start" on the windows menubar to "shut down".
And I work for a railroad that moves a half-million people a day. I like to think they're not too dissimilar industries - when my computers shut down, the railroad stops running. I'm guessing that when your computer stops, the ship stops moving. That it doesn't sink or explode (i.e. there are hardware items that relieve excess pressure, etc.)
There are some differences. My trains have low-level hardware (based around gobs of vital relays) that will stop them from running into each other. I doubt ships have anything like this.
The standards for what you or I do are drastically different from what someone writing software for an airplane's fly-by-wire system has to do. There, if the computer stops or starts doing the wrong thing, it falls out of the sky. Scary stuff.
So, it depends on what the computer controls, but you haven't given us this information.
The most paradoxical comment within this letter is this:
In other words, he think that the way to protect his intellectual property is to ask that it be illegal for others to give away their intellectual property. And this isn't too much to ask. Scary thought.He also seems to give the RIAA implicit control over all music, but that's another flame war.
I'm not saying that Open Source Intelligence is a bad thing; just that the gullibility index of interpreters will be a major fact into how useful it becomes.
But you're just a high-school student. I don't mean to belittle you with that, but to devote your career to academics at this point is a bit early. Certainly, get your degree in math if that's what you love. Go to grad school in math and then you'll start to get the flavor of what life is like in academics. You'll also (hopefully) learn about the job market there.
Yes, you probably can stay in academics all your life. You might not like it, though. You might have to do research in areas you aren't interested in; for part of your career you might have very little time to do anything but teach (while at the same time you really also have to be publishing!). You'll almost certainly be looking at moving around a lot, first to grad school, then to a series of postdocs at different institutions, then start moving up the ranks towards tenure (which often involves moving sideways to other institutions, too.) If you love travel and not settling down, it's great. If you're looking for stability, it may not be for you.
You'll also be able to go into many industries or branch out into some other area. Mathematicians are in demand in a number of different areas (some of which you may not enjoy, though.)
Don't box yourself in at this point. In fact, it's hard to box yourself in until grad school. So do what you enjoy, discover new things, have fun!
Right now, of course, those mail-ordering from out-of-state retailers are supposed to remit the sales tax by filing all the paperwork and sending a check to the state. But individuals rarely (if ever?) do this. Many businesses (who are supposed to be doing this on any expense) don't do this either, though they get caught at it fairly often by state income tax audits.
California actually is pretty good at finding out-of-state car buys and collecting tax on them, but the paperwork involved with registering a car makes sure these get put in the system. Are we gonna have to register our CRT's with the DMV?
Now that anti-hydrogen is so easily made, I just have to wait until they make anti-oxygen too. Combine them to make anti-H2O, and when I drink it it'll make thirsty...
This is just plain wrong. Does this mean the teenage girl is a criminal for having gone to the authorities?
This situation doesn't make sense to me. In the Clinton-Monica case, Monica wasn't a victim (at least not in any normal sense of the word.)
In the Pennsylvania case, the victim went to the police after getting requests for sex from the perp. Am I being told that the victim wasn't allowed to do this (and, as an extension, because the victim didn't get the perp's permission first, that she's now a criminal for having gone to the police?)
There's very little in common. TWACS works by doing phase-shift modulation on the 60Hz carrier; this is a wonderfully robust method when implemented correctly, but at best you get a bandwidth of a few tens of bits per second. This is great for reading power meters (where a few bits per hour is plenty of bandwidth) but it has nothing to do with high-speed internet connections.
Fuji M2388, Kennedy Data units, etc. Of course, when your drive platters are 14" and the head arms are nearly a foot long it's a lot more impressive - not much purpose for doing this on a dinky 5.25" drive!
As is a T3, and OC3, and everything else by your standards. (Actually the cost/Mbps for an OC3 can be discounted substantially over a single T1.)
You don't seem to grasp the fact that the cable ISP *is* paying for a couple T1's or a T3.
Or, at least I hope they are. If their plan is to get their connectivity by a long piece of coax running to the provider in the next town and paying $50/month, that would explain the service level that many cable customers are seeing :-)
I've gotten even less idea what you're doing, but MRTG can track traffic usage for an amazingly wide number of network (and non-network!) interfaces. If your interface supports SNMP it's automatic; if it doesn't, there is probably some way of dealing with it.
Check out my network usage for an example - integrate the area under the curve and you have net hourly/daily/weekly/monthly/yearly usage, and you can look at the peaks to determine peak (5-min avg) usage. It even keeps track of that machine's CPU temperature and fan speed.