If gravity moved at the speed of light, then
the Earth, in it's orbit, would "see" the Sun
where it was about 8 minutes ago. Over geologic
time, this changes the orbit. Over the life of
the solar system, Earth's orbit isn't stable.
So, gravity much act faster. One estimate of
the speed of gravity is that it must be at
least 10^15 times faster than light. That means
that the wavelengths may be very short. So, using
light interferometry to detect them may be futile.
There may still be things to learn from the experiment,
however, even if it isn't about gravity.
For any heat base power generation system, like
nuclear, gas, coal, oil, the best efficiency that
thermodynamics allows is 50%. So, a 1 Gigawatt
power plant must produce at least 1 gigawatt of
heat. We used to dump this into our rivers.
But a 10 megawatt plant on the Connecticut river
would raise the temperature of the river by 10
degrees F, forever. This is an ecological disaster,
not because it's 10 degrees, but because it's instant.
Ecosystems require more time than instant to
adapt.
Dumping the heat into the air gets rid of the
heat pretty well. That's what the hyperbolic towers are for. Most of the heat radiates into space.
A Nuke plant's pollution is thus mainly a little
waste heat. Of course, the gigawatt of electrical
power eventually is turned into heat, too.
Nuke plants are pretty expensive to operate. You
have to be extremely careful, which costs money.
The cost of fuel is quite low - nearly insignificant, like $10/megawatt hour.
There is a hidden cost, and I'm not sure that
it has been paid yet. Once the fuel is consumed,
it must be disposed of. At the moment, we're
storing the spent fuel at the Nuke plant. This
is a short term stopgap proceedure. We need
a longer term solution. The current proposed
solution in the US is very late, and way over
budget. Since you must store the spent fuel
for a million years, you must store it in a
geologically benign place. Since a million years
is a long time, I'd argue that no such place
exists. So, you have to design it so that
it is possible to move the fuel from time to time.
This will provide us with an additional cost
stream forever.
The other cost is that, statistically, there will
be other 3 Mile Island, Chernobyl, etc., incidents.
The more plants you run, the higher the chances.
The UK is talking about ramping up to 10% of their
power derived from wind energy. It is expected
to be competitive with other power types.
Solar power isn't currently considered viable, but
should become so pretty soon.
At the moment, we heat our houses by burning more
fossile fuels. We could heat them by using waste
heat from electrical power plants. Purdue University
runs it's own electrical power plant, and heats
the campus as a side effect. It's not a new idea.
Conservation provided the US most of the way out
of the 70's energy crisis. Reducing the highway
speed limit saved about 15% in fuel. And, it happens
instantly - despite what President Bush said.
We don't really have to drive gas guzzling SUVs.
My primary car averages about 33 MPG. It's a 4
door sedan, about 14 years old. I'd like to
replace it with something more efficient. Several
products are available and affordable.
I've started replacing incandescant lights in the
house with screw-in flouresant bulbs. These last
longer, produce the same light but use much less power
and produce less heat. I'm finding that I can't
use them everywhere, but they work in most places.
My electric bill is lower.
Upgrades are painful. When the vendor makes big
changes, upgrading to another vendor reduces the
differences in costs. If the Air Force wants
better security, they'll need to upgrade. The cost
of upgrading to, say, Linux, may be cheaper than
the cost of upgrading to the next MS product.
And, the security implications may be well understood
by then.
The costs that many are concerned with are
new applications checkout and user education.
When a local church was considering upgrading
their Windows 3.1 system to 95, 98 or NT, I
suggested that it would be just as easy to
upgrade to a Mac. The secretary didn't know
how to use anything other than WordPerfect, and
the new Pastor already knew how to use a Mac.
That left teaching the secretary how to boot
and shut down the Mac - which you'd have to do
with 95, 98 or NT. Naturally, the Air Force would
have more work to do.
When the DOJ case came out, at least one comment
circulating was that the US should simply stop
buying MS products - as that would cost MS more.
As I understand it, this is the China solution.
Alkaline rechargables seem to work. Things I like
are that the charger (Rayovac) can charge a single
battery at a time. Several devices I use consume an odd number of batteries.
Evidence suggests that it's
better for the batteries to be stored charged.
They can be recharged at any time, so they're
more likely ready for use.
Things I dislike are that they seem to last half
the time of NiMH, per charge. Unlike NiCad or NiMH, their
voltage drops slowly with use. This makes my
walkman's pitch drop slowly. NiCad or NiMH hold
voltage until almost out of juice, so the pitch
stays nearly constant.
Rechargable alkalines have extremely poor cold
temperature performance. This is bad for
powering my telescope in the winter.
Yet, rechargable alkalines do OK at things that
alkalines do - like power wall clocks for months,
or sitting in a child's toy awaiting use.
My experimentation set has already paid for itself
and the charger.
I wouldn't use them for a laptop or pda.
I do use NiMH for my Handspring Palm. No, the
unit does not recharge them. I pop in my spare
set of AAA's every now and then.
At the moment, batteries are a way of life.
Rechargables are cheaper. If there are rechargables,
I use the device. I'm not using it up - I can
always get another cycle out of the batteries.
A battery that gets 100 cycles has got to be
more environmentally friendly than a battery that
gets one cycle.
I'm surprised the article didn't mention flywheel batteries. One company reports a 50:1 energy to weight advantage over lead acid batteries. (How does that compare to Lithium?). You add energy electrically - a motor spins up the flywheel. You get it out electrically - a generator takes energy from the flywheel. To reduce friction, the flywheel sits in a vacuum, and uses a magnetic bearing. 17,000 RPM. They claim a 5% loss per day. It would be nice to be able to add energy at a high rate - like at a kilowatt. No memory. When the device no longer functions, there are no toxic chemicals.
I'd like a laptop that runs for 100 hours between charges, and charges in a minute. I'd like to be able to add energy by hand crank, solar cell, car plug or house plug without funky adapters to lug around.
There is talk of putting flywheel batteries on the space station. Twin counter rotating flywheels reduce torque on the station.
When my 386 was new, I ran some file system tests on ext2.
I did not write a master thesis.
How much performance is lost if the 5% reserve is removed?
I created a file system with the default 5% reserve. I
ran a bechmark which created a large file and deleted it
in a loop. I then filled the file system to 90%, and reran
it. I then created the file system with 0% reserver, filled
it to 90% and reran it. The results were that there was
no measurable difference. The conclusion was that
the 5% reserve does not help performance. Since then,
I have routinely created ext2 file systems without any reserve.
I did not attempt to purposely fragment the file system.
It's clear that this could make a big difference. However,
since '94, it doesn't seem to have made any difference. For
one thing, my file systems don't tend to fill up beyond 95%
very often.
After three years of heavy use on my current system, my worst
file system shows 3% files as not contiguous. These files may
be ones that are newer, and may have heavy use - I don't know.
However, the file system does not seem to be significantly
slower than it was when it was new.
If I had a defrag utility, I probably would not use it at this
time. I would be more inclined to perform a backup, perform
an exhaustive disk test, recreate the file system, and perform
a restore. The disk hasn't been tested in three years. My oldest
drives died at about 8 years. It's probably time to test it.
There just does not seem to be much requirement for an in-place
defrag utility for Linux ext2. There may be one for other
Linux file systems. I do not view the lack of a defrag utility
as a defect in Linux, but rather high praise for ext2.
In the V7 Unix days, the file systems naturally fragmented.
Files were contiguous only when the file system was freshly
created. The backup/recreate/restore proceedure was the only
way to defrag a disk. Since this required the file system to
be off line for the duration, and since these were expensive
multi-user systems, it did not happen often. I tended to do
it for relatively static file systems, such as/usr, and then
only very infrequently. Even so, there was not much performance
difference.
General Aviation aircraft sales went to nearly
zero due to liability suits. Companies like
Cessna shut down their production lines. After
several years, a new law was passed (in the US)
limiting liability to 20 years. Companies like
Cessna reopened production.
If software users carry liability insurance,
as is the case for cars, then at least,
they could go to the insurance company and say, "I
want to buy a web server. What does insurance
cost for various web servers?". Then one could get
a safer web server, just like one can get a safer car. Instead of buying software based on the
manufacturer's FUD, one buys it based on
the insurer's libability.
For Windows, Mac, X Windows, the solution is
to tie the desktop metaphore directly to the
file system. There should be an application
to control files. There should be an application
to save short cuts to applications that the user
feels are important. There should be one or
a small number of places to put temporary files.
These apps need to be accessible all the time,
ie, some sort of menu that is always visible.
After all, most windows have a button that allows
them to consume the entire screen. No desktop.
PC Jr. had wireless keyboard
on
Concept PC 2001
·
· Score: 1
The PC Jr.'s keyboard was IR. It suffered from
IR things - like not always working when the
curtains were open. Still, the PC Jr. didn't die
because of the keyboard. It died because it
wasn't quite compatible.
With RF, I might be
concerned that I'd have yet another plain
text connection that could be snooped.
Does anyone remember when keyboards were attached
to the terminal? It was such a nice thing
when, finally, you could put the thing in your
lap. Now we have the Enterprise class keyboard (named
after the aircraft carrier, which it resembles.
There are all these extra keys on one side.
So in the lap, the keyboard is an out of balance accident
waiting to happen.
Laptops have nice compact keyboards
that you can put in your lap, but the monitor
goes into your lap too.
In 1987, 1995 and 1999, I went with SCSI.
My boot drive is internal, and my backup drive
is external, and normally turned off. This
is important, as at least one drive failure
mode I've experienced was power related. All
powered on drives died in the event.
SCSI is faster than fire wire, and more mature.
History has show SCSI to be upgradable over
time. My 1987 system is still in production
operation. I can still buy drives and other
devices for it. I have a SCSI CD drives,
CD burner, disk drives, scanner, and tape drive.
Many of these items did not exist in 1987.
SCSI has improved in speed over the years,
and the high end server market has kept SCSI
alive and well. For me, extending the life of
the original system allowed me to expand it
in hardware and software, improving cost performance.
Fire wire may be twice as fast as IDE, but my
experience is that SCSI is more like four times
faster. For example, under Linux, I get
2-5 MB/sec with IDE and 11-25 MB/sec with SCSI.
You can spend an extra few hundred dollars on
your system and have a slightly faster CPU.
You can spend less on your I/O system and
quadruple the speed. Given today's bloatware,
you tend to be waiting for I/O rather than
CPU cycles. So, by and large, the place to
spend your money for performance is I/O.
And if you upgrade your system, chances are,
you'll be able to move your SCSI hardware forward,
as I have done.
Cross platform GUIs have several problems.
First, they generally do not support the native
human interface guidelines of each platform.
Even if they do, your application tends to
behave like only one platform. So, if your
intended "final" platform is *nix, then find
a GUI that allows you to create a *nix interface.
Secondly, cross platform GUIs are usually a
layer between some native GUI library and you.
This involves overhead in speed and size.
If you are considering C or C++, it is possible
that speed and size are important to you.
Denning held back page replacement by "proving"
that you couldn't do any better than his "working
set". An assumption that it was based on was
that you couldn't predict future activity.
Naturally, this is wrong. Sequential access
and random access patterns can be predicted
by the OS, and the programs themselves can
be compiled to give additional hints.
The paper seems to say that software development
is like the halting problem. You can't tell
if a program will halt or not without essentially
running it. You can't tell how long it will take
to write something without writting it.
However, a short program like:
for i = 1 to N then
x = x + 1
next i
can easily be shown to halt in less time than
order N.
With software development, it is the same.
If you break down the project into small pieces,
you can analyse the pieces and add up the
estimates. Many of the pieces will be familiar,
so the estimates are faster than doing them
from scratch. For experienced estimaters, this
should be most of the pieces. The real problem
is that people make mistakes, and miss pieces.
Missed pieces invariably require more time.
Estimation is overhead. At some point in
the estimation of any project, the cost of
refining the estimate is larger than the cost
of adding padding to the real project to cover
these details. This is reasonable, and is
a good justification to limit rigor in estimation.
But, it can lead
to missing important details that will take
a long time, degrading the accuracy of the
project.
The paper also seems to concentrate on the
largest projects. But large project are most
often just the integration of several smaller
projects. Small projects can be estimated.
Integration of small projects, especially those
designed to work together, can be estimated.
The paper talks about projects where the goal
is something that has never been done before.
In my experience, this is extremely rare.
But here, I agree that estimating progress
is extraordinarily difficult.
Of the projects that I've estimated, only a
small fraction have turned out to take longer
than the estimate. In a small fraction of
these, some aspect of the task escaped the
estimate. In the vast majority of cases,
something was changed that violated an assumption.
This might have been scope creap or change,
change in personnell, or delay in some external
factor. This is life in the software business.
In many cases, a clear contract can keep everyone
honest and eliminate these sources.
No one likes it when a billion bucks is spent
and the partial results are thrown out. It nearly
always turns out to be some well known phenomenon.
Ford's current practice is to keep the budget
constant, keep the schedule constant, and in
a crunch, discard functionality. The customer
has input on what gets discarded. Often, discarded
functionality makes it into the next phase.
The Demudi Linux (Debian) based music distribution
is just getting going. Judging by the mailing
list, it appears that there are enough people
to get the project to move forward. MIDI won't
be the first priority for the group (though, an
individual might have that priority, who knows?),
but it will be a priority soon. This isn't the
commercial world. Projects with essentially
zero overhead can survive hibernation.
In the early 80's, I asked around if anyone needed
certain types of graphic support. One guy said,
"Don't bother with it, no one is doing it." My
attitude at the time was that no one was doing
it because they couldn't. When I provided support,
it became extremely popular.
At the moment, I don't know anyone doing MIDI
stuff on Linux. When it becomes easier, as I
expect with Demudi, it will be much more common.
The current generation of commercially available
heat pumps is already in use. They use heat
sinks to cool the hot side of the wafer, and
CPU fans to transfer heat from the heat sink
to the air, and, of course, the box has a fan
to replace hoter air with room air.
An IMac has no fan. The CRT is hot enough to generate
a significant draft. Thus convective cooling
is adequate. Last I heard, the IMac motherboard
is essentially a laptop motherboard.
There used to be all-in-one PCs with convective
cooling, but someone used FUD advertising to
run them out of business.
I'd like to have my PC's sound card hooked up
to my main home stereo, but it's too noisy.
I did bring down the noise by replacing the fans.
I've just installed the alpha distribution.
I'd like to give it a rave, but, uhm, it's
still alpha, and I haven't gotten it to
recognize my sound card. Red Hat did.
The point of the article was that the last 5%
of CPU costs %30 more.
At the very high end - supercomputing, cost
performance is everything. However, the article
talks about chip costs, not system costs.
Low end CPUs have been adequate for
a long time. Low end systems sacrifice expandability.
My 1987 Mac II (16.7 MHz) is still my best word processor.
This Mac was high end, but it's unlikely that I'd still be using a Mac SE.
For one thing, you couldn't change the monitor.
I buy capabilities:
word processor, scanner, line art editing and photo editing and printing, MIDI and sound recording and editing with CD burning,
development tools, web server, database,
local network,
voice mail and fax, internet access, backup,
and reliability. I spent extra for a quiet
fan. That helps me concentrate better, and
saves me more time than a faster CPU.
In the early SMP Unix days (mid 1980s)
when parallel make became available,
a single CPU would benefit from parallel
compiles.
The single CPU was usually 60% idle during a single compile.
The rest of the time was spent waiting for disk.
Thus, I was surprised that the single CPUs
didn't gain from multiple processes, and duals
didn't gain from more than two. This benchmark
is clearly CPU bound, not disk bound. In
particular, faster disks won't change anything.
It may be that slower disks won't change anything
either.
That could be because of:
gcc -pipe
RAM disk
read ahead/write behind in the filesystem
massive kernel buffering, and taking the
second test time.
It seems likely that "make -jN" is what was used
to achive multiple processes.
It seems unlikely that a RAM disk was used.
I have the Java bookshelf CD. Searching works
in Linux and Windows. It's pretty sad that
it works for the Java CD, but not for Perl.
Perhaps they'll cut fixed CDs by the time I need
it. I can cut CDs at home, so perhaps I could
cut myself a fixed CD.
For dog ears, I use my browser's bookmarks.
If I wanted, I could publish these bookmarks
on my web site, so I could have my dog ears
at home or at work.
I disagree - searching the CD is faster than
searching dead trees. I find myself doing:
zgrep -i sometext/usr/man/man1/perl*
and even that's faster than looking it up
in dead trees.
My biggest problem with the CD is the desktop
computer. I can read dead trees anywhere, but
my laptop doesn't have a CD drive or wireless
network. Also, I read dead trees faster than
a CRT. I'm not sure why. Maybe it's that
dead trees don't make as much noise.
Slashdot Mirror
If gravity moved at the speed of light, then the Earth, in it's orbit, would "see" the Sun where it was about 8 minutes ago. Over geologic time, this changes the orbit. Over the life of the solar system, Earth's orbit isn't stable. So, gravity much act faster. One estimate of the speed of gravity is that it must be at least 10^15 times faster than light. That means that the wavelengths may be very short. So, using light interferometry to detect them may be futile. There may still be things to learn from the experiment, however, even if it isn't about gravity.
Dumping the heat into the air gets rid of the heat pretty well. That's what the hyperbolic towers are for. Most of the heat radiates into space.
A Nuke plant's pollution is thus mainly a little waste heat. Of course, the gigawatt of electrical power eventually is turned into heat, too.
Nuke plants are pretty expensive to operate. You have to be extremely careful, which costs money. The cost of fuel is quite low - nearly insignificant, like $10/megawatt hour.
There is a hidden cost, and I'm not sure that it has been paid yet. Once the fuel is consumed, it must be disposed of. At the moment, we're storing the spent fuel at the Nuke plant. This is a short term stopgap proceedure. We need a longer term solution. The current proposed solution in the US is very late, and way over budget. Since you must store the spent fuel for a million years, you must store it in a geologically benign place. Since a million years is a long time, I'd argue that no such place exists. So, you have to design it so that it is possible to move the fuel from time to time. This will provide us with an additional cost stream forever.
The other cost is that, statistically, there will be other 3 Mile Island, Chernobyl, etc., incidents. The more plants you run, the higher the chances.
The UK is talking about ramping up to 10% of their power derived from wind energy. It is expected to be competitive with other power types.
Solar power isn't currently considered viable, but should become so pretty soon.
At the moment, we heat our houses by burning more fossile fuels. We could heat them by using waste heat from electrical power plants. Purdue University runs it's own electrical power plant, and heats the campus as a side effect. It's not a new idea.
Conservation provided the US most of the way out of the 70's energy crisis. Reducing the highway speed limit saved about 15% in fuel. And, it happens instantly - despite what President Bush said.
We don't really have to drive gas guzzling SUVs. My primary car averages about 33 MPG. It's a 4 door sedan, about 14 years old. I'd like to replace it with something more efficient. Several products are available and affordable.
I've started replacing incandescant lights in the house with screw-in flouresant bulbs. These last longer, produce the same light but use much less power and produce less heat. I'm finding that I can't use them everywhere, but they work in most places. My electric bill is lower.
The costs that many are concerned with are new applications checkout and user education.
When a local church was considering upgrading their Windows 3.1 system to 95, 98 or NT, I suggested that it would be just as easy to upgrade to a Mac. The secretary didn't know how to use anything other than WordPerfect, and the new Pastor already knew how to use a Mac. That left teaching the secretary how to boot and shut down the Mac - which you'd have to do with 95, 98 or NT. Naturally, the Air Force would have more work to do.
When the DOJ case came out, at least one comment circulating was that the US should simply stop buying MS products - as that would cost MS more. As I understand it, this is the China solution.
Evidence suggests that it's better for the batteries to be stored charged. They can be recharged at any time, so they're more likely ready for use.
Things I dislike are that they seem to last half the time of NiMH, per charge. Unlike NiCad or NiMH, their voltage drops slowly with use. This makes my walkman's pitch drop slowly. NiCad or NiMH hold voltage until almost out of juice, so the pitch stays nearly constant.
Rechargable alkalines have extremely poor cold temperature performance. This is bad for powering my telescope in the winter.
Yet, rechargable alkalines do OK at things that alkalines do - like power wall clocks for months, or sitting in a child's toy awaiting use. My experimentation set has already paid for itself and the charger.
I wouldn't use them for a laptop or pda.
I do use NiMH for my Handspring Palm. No, the unit does not recharge them. I pop in my spare set of AAA's every now and then.
At the moment, batteries are a way of life. Rechargables are cheaper. If there are rechargables, I use the device. I'm not using it up - I can always get another cycle out of the batteries. A battery that gets 100 cycles has got to be more environmentally friendly than a battery that gets one cycle.
batteries. One company reports a 50:1 energy to
weight advantage over lead acid batteries. (How
does that compare to Lithium?). You add energy
electrically - a motor spins up the flywheel.
You get it out electrically - a generator takes
energy from the flywheel. To reduce friction, the
flywheel sits in a vacuum, and uses a magnetic
bearing. 17,000 RPM. They claim a 5% loss per day. It would
be nice to be able to add energy at a high rate -
like at a kilowatt. No memory. When the device
no longer functions, there are no toxic chemicals.
I'd like a laptop that runs for 100 hours between
charges, and charges in a minute. I'd like to
be able to add energy by hand crank, solar cell,
car plug or house plug without funky adapters
to lug around.
There is talk of putting flywheel batteries on
the space station. Twin counter rotating flywheels
reduce torque on the station.
When my 386 was new, I ran some file system tests on ext2. I did not write a master thesis. How much performance is lost if the 5% reserve is removed? I created a file system with the default 5% reserve. I ran a bechmark which created a large file and deleted it in a loop. I then filled the file system to 90%, and reran it. I then created the file system with 0% reserver, filled it to 90% and reran it. The results were that there was no measurable difference. The conclusion was that the 5% reserve does not help performance. Since then, I have routinely created ext2 file systems without any reserve. I did not attempt to purposely fragment the file system. It's clear that this could make a big difference. However, since '94, it doesn't seem to have made any difference. For one thing, my file systems don't tend to fill up beyond 95% very often.
After three years of heavy use on my current system, my worst file system shows 3% files as not contiguous. These files may be ones that are newer, and may have heavy use - I don't know. However, the file system does not seem to be significantly slower than it was when it was new.
If I had a defrag utility, I probably would not use it at this time. I would be more inclined to perform a backup, perform an exhaustive disk test, recreate the file system, and perform a restore. The disk hasn't been tested in three years. My oldest drives died at about 8 years. It's probably time to test it.
There just does not seem to be much requirement for an in-place defrag utility for Linux ext2. There may be one for other Linux file systems. I do not view the lack of a defrag utility as a defect in Linux, but rather high praise for ext2.
In the V7 Unix days, the file systems naturally fragmented. Files were contiguous only when the file system was freshly created. The backup/recreate/restore proceedure was the only way to defrag a disk. Since this required the file system to be off line for the duration, and since these were expensive multi-user systems, it did not happen often. I tended to do it for relatively static file systems, such as /usr, and then
only very infrequently. Even so, there was not much performance
difference.
If software users carry liability insurance, as is the case for cars, then at least, they could go to the insurance company and say, "I want to buy a web server. What does insurance cost for various web servers?". Then one could get a safer web server, just like one can get a safer car. Instead of buying software based on the manufacturer's FUD, one buys it based on the insurer's libability.
For Windows, Mac, X Windows, the solution is to tie the desktop metaphore directly to the file system. There should be an application to control files. There should be an application to save short cuts to applications that the user feels are important. There should be one or a small number of places to put temporary files. These apps need to be accessible all the time, ie, some sort of menu that is always visible. After all, most windows have a button that allows them to consume the entire screen. No desktop.
With RF, I might be concerned that I'd have yet another plain text connection that could be snooped.
Does anyone remember when keyboards were attached to the terminal? It was such a nice thing when, finally, you could put the thing in your lap. Now we have the Enterprise class keyboard (named after the aircraft carrier, which it resembles. There are all these extra keys on one side. So in the lap, the keyboard is an out of balance accident waiting to happen.
Laptops have nice compact keyboards that you can put in your lap, but the monitor goes into your lap too.
In 1987, 1995 and 1999, I went with SCSI. My boot drive is internal, and my backup drive is external, and normally turned off. This is important, as at least one drive failure mode I've experienced was power related. All powered on drives died in the event.
SCSI is faster than fire wire, and more mature. History has show SCSI to be upgradable over time. My 1987 system is still in production operation. I can still buy drives and other devices for it. I have a SCSI CD drives, CD burner, disk drives, scanner, and tape drive. Many of these items did not exist in 1987. SCSI has improved in speed over the years, and the high end server market has kept SCSI alive and well. For me, extending the life of the original system allowed me to expand it in hardware and software, improving cost performance.
Fire wire may be twice as fast as IDE, but my experience is that SCSI is more like four times faster. For example, under Linux, I get 2-5 MB/sec with IDE and 11-25 MB/sec with SCSI.
You can spend an extra few hundred dollars on your system and have a slightly faster CPU. You can spend less on your I/O system and quadruple the speed. Given today's bloatware, you tend to be waiting for I/O rather than CPU cycles. So, by and large, the place to spend your money for performance is I/O. And if you upgrade your system, chances are, you'll be able to move your SCSI hardware forward, as I have done.
Cross platform GUIs have several problems. First, they generally do not support the native human interface guidelines of each platform. Even if they do, your application tends to behave like only one platform. So, if your intended "final" platform is *nix, then find a GUI that allows you to create a *nix interface.
Secondly, cross platform GUIs are usually a layer between some native GUI library and you. This involves overhead in speed and size. If you are considering C or C++, it is possible that speed and size are important to you.
The paper seems to say that software development is like the halting problem. You can't tell if a program will halt or not without essentially running it. You can't tell how long it will take to write something without writting it. However, a short program like:
for i = 1 to N then
x = x + 1
next i
can easily be shown to halt in less time than order N.
With software development, it is the same. If you break down the project into small pieces, you can analyse the pieces and add up the estimates. Many of the pieces will be familiar, so the estimates are faster than doing them from scratch. For experienced estimaters, this should be most of the pieces. The real problem is that people make mistakes, and miss pieces. Missed pieces invariably require more time.
Estimation is overhead. At some point in the estimation of any project, the cost of refining the estimate is larger than the cost of adding padding to the real project to cover these details. This is reasonable, and is a good justification to limit rigor in estimation. But, it can lead to missing important details that will take a long time, degrading the accuracy of the project.
The paper also seems to concentrate on the largest projects. But large project are most often just the integration of several smaller projects. Small projects can be estimated. Integration of small projects, especially those designed to work together, can be estimated.
The paper talks about projects where the goal is something that has never been done before. In my experience, this is extremely rare. But here, I agree that estimating progress is extraordinarily difficult.
Of the projects that I've estimated, only a small fraction have turned out to take longer than the estimate. In a small fraction of these, some aspect of the task escaped the estimate. In the vast majority of cases, something was changed that violated an assumption. This might have been scope creap or change, change in personnell, or delay in some external factor. This is life in the software business. In many cases, a clear contract can keep everyone honest and eliminate these sources.
No one likes it when a billion bucks is spent and the partial results are thrown out. It nearly always turns out to be some well known phenomenon.
Ford's current practice is to keep the budget constant, keep the schedule constant, and in a crunch, discard functionality. The customer has input on what gets discarded. Often, discarded functionality makes it into the next phase.
Total hits:
(code red) default.ida: 14630
(nimda?) winnt: 100248
(nimda) root.exe: 17475
I don't see any "dir+c" strings in my logs, but I do see "winnt/system32/cmd.exe?/c+dir" I have one less "winnt.*c+dir" than just winnt, total.
Since Oct 4th:
(code red) default.ida: 3
(nimda?) winnt: 34884
(nimda) root.exe: 5657
Yes. Most of my web server's activity has been in response to these worms.
In the early 80's, I asked around if anyone needed certain types of graphic support. One guy said, "Don't bother with it, no one is doing it." My attitude at the time was that no one was doing it because they couldn't. When I provided support, it became extremely popular.
At the moment, I don't know anyone doing MIDI stuff on Linux. When it becomes easier, as I expect with Demudi, it will be much more common.
I've even seen water cooled PCs.
There used to be all-in-one PCs with convective cooling, but someone used FUD advertising to run them out of business.
I'd like to have my PC's sound card hooked up to my main home stereo, but it's too noisy. I did bring down the noise by replacing the fans.
I've just installed the alpha distribution. I'd like to give it a rave, but, uhm, it's still alpha, and I haven't gotten it to recognize my sound card. Red Hat did.
My 1987 Mac II (16.7 MHz) is still my best word processor. This Mac was high end, but it's unlikely that I'd still be using a Mac SE. For one thing, you couldn't change the monitor.
I buy capabilities: word processor, scanner, line art editing and photo editing and printing, MIDI and sound recording and editing with CD burning, development tools, web server, database, local network, voice mail and fax, internet access, backup, and reliability. I spent extra for a quiet fan. That helps me concentrate better, and saves me more time than a faster CPU.
In the early SMP Unix days (mid 1980s) when parallel make became available, a single CPU would benefit from parallel compiles. The single CPU was usually 60% idle during a single compile. The rest of the time was spent waiting for disk. Thus, I was surprised that the single CPUs didn't gain from multiple processes, and duals didn't gain from more than two. This benchmark is clearly CPU bound, not disk bound. In particular, faster disks won't change anything. It may be that slower disks won't change anything either.
That could be because of:
gcc -pipe
RAM disk
read ahead/write behind in the filesystem
massive kernel buffering, and taking the second test time.
It seems likely that "make -jN" is what was used to achive multiple processes. It seems unlikely that a RAM disk was used.
I have the Java bookshelf CD. Searching works in Linux and Windows. It's pretty sad that it works for the Java CD, but not for Perl. Perhaps they'll cut fixed CDs by the time I need it. I can cut CDs at home, so perhaps I could cut myself a fixed CD.
For dog ears, I use my browser's bookmarks. If I wanted, I could publish these bookmarks on my web site, so I could have my dog ears at home or at work.
I disagree - searching the CD is faster than searching dead trees. I find myself doing: /usr/man/man1/perl*
zgrep -i sometext
and even that's faster than looking it up in dead trees. My biggest problem with the CD is the desktop computer. I can read dead trees anywhere, but my laptop doesn't have a CD drive or wireless network. Also, I read dead trees faster than a CRT. I'm not sure why. Maybe it's that dead trees don't make as much noise.