Given that entropy is the measure of order or
disorder.
The difficulty is in this first step. It's not
like you can go to the hardware store and buy
an "entropymeter" like you can a voltmeter or
thermometer. So how do you measure entropy?
i.e. how do you look for patterns in data when you
might not even understand the process that
creates the data? We do have some tools (heck,
I like bzipping the original and comparing
compressed with uncompressed file sizes) but they
do not find all relevant patterns by any
means.
I'm not saying that entropy is a useless concept;
I'm just saying that it's not an easy thing to
measure in complex (AI-type) systems. When your
tool fails to detect a pattern it will increase
your measured entropy, but the pattern is still
there. I am extremely unconfortable if changing
my tool changes my measure of the entropy.
In order to really make a single fat
pipe you need hardware and/or software
at both ends of the connection to do the
aggregation. Are you connecting, say, a
remote business office with headquarters? If
so, the Stallion approach you already mentioned should work fine,
as you can coordinate the equipment on both ends.
I get the impression from your rejection of
load balancing that you are more typically on
the "client" rather than the "server" end of
a connection. (Or maybe you're a server
with only a single client, in which case
load balancing probably doesn't help either.)
If you're a guy in his house who wants a fatter
pipe to download single big files, you probably
cannot get the folks at the server to install
special equipment for you. If your ISP will help you to support aggregation by putting equipment on their end
to hook into their upstream connection, that's
not so bad, and some small regional ISP's do specialize
in this. But you'll have to tell us where you
are to get a recommendation for such ISP's.
IMHO the most likely things to be salvaged from
an old PC are the case and power supply. Make sure the case will take a new ATX motherboard, and
be sure the power supply has enough oomph to run
the new motherboard.
Others might quibble about testing the existing
(small) hard drives, floppy drive, and CD-ROM, but
I'd just count on trashing these items. They're
cheap and plentiful new. Besides, if you're
buying massive numbers of machines to administer
in a giant cluster, you probably don't need or
want any removable media on each machine.
Same goes for whatever existing motherboards might be in the machines. If they're a couple years old you'd probably have to go hunting around the net to find BIOS updates etc. to make them work with
your peripherals. It's not worth the time, especially with decent new motherboards available for a half-hour's pay.
Anyone know what percent of our national power is used on computers?
I don't know the number, but the trend is disturbing. I would have naively thought that as
computers get more and more computational power
while their power requirements per computational power decrease
that the
number of computers needed would decrease. Instead, the number of computers seem to be
multiplying. Even I'm guilty of it; add
a firewall here, add a web server there, add a NAS box in the room.
I do appreciate your desire
for a low-power consumption box. And I do
appreciate that your computing solution only
involves a single box. Good luck in your search.
Many of today's programmers are curiously
nonchalant about Y2038, when Unix and other OS's
that store the date in number of seconds since
1970 in a 32-bit signed quantity overflow and
the date goes negative. The vast majority
lump it into the somebody else's problem
category, for one of several reasons:
They won't be around.
Surely the date field will expand to 64 bits by then.
They plan on making a lot of money 36 years from now
Almost all of these were uttered in that Google thread from 1985 about Y2K:-)
Strangely, though, few seem to care that there
are many file formats where the "automatic" kernel 64-bit date expansion they expect will
be a problem. If the application expects that
the date will always fit in that 32-bit field, and there's no obvious way to extend that field, then you have a lot of files which
may no longer be useful...
He is only encouraging those who
accidently find weaknesses to responsibly report them.
The thing is, network security weaknesses are
rarely accidental. You can reliably
predict the top five causes of security weaknesses:
Buffer overflows
Buffer overflows
Buffer overflows
Buffer overflows
Buffer overflows
There's nothing at all accidental about why those
are where the security weaknesses are - it's because most services are written in languages that make it very easy to overflow a buffer. What
we need is a law that makes it a crime to do such
poor software engineering.
The Very Large Array, one of the world's premier astronomical radio observatories, consists of 27 radio
antennas in a Y-shaped configuration on the Plains of San Agustin fifty miles west of Socorro, New Mexico.
Each antenna is 25 meters (81 feet) in diameter. The data from the antennas is combined electronically to give
the resolution of an antenna 36km (22 miles) across, with the sensitivity of a dish 130 meters (422 feet) in
diameter.
Thank you for the link about Debian and libjpeg62; I suspect that if they think it's encumbered then the other Linux distros will go the same way.
It won't affect me much, as my systems
are all built from sources. And most of the tools that can potentially do jpegs can be built without jpeg support. But it's sad to hear that users of binary Linux distros may be hurt by this.
How does this affect libjpeg, which comes as
part of nearly (OK, not in my favorite, Linux From Scratch) every Linux distribution?
It's clear
that Forgent is going after companies that
develop browsers, sell image editing tools,
etc., but on your typical Unix/Linux platform these tools often are
"just" linked to libjpeg where the real encoding
and decoding is done. In this case might they
try to go after anyone whose name appears in the
libjpeg sources? Ack!
The item you are looking for is known as a
"digital back", and indeed it is a detector
that sits on the film plane.
The problem for you is that your cameras probably
do not have interchangable backs. There are
very few 35mm cameras
that have interchangeable or digital backs;
see this web page for an example that does. In the "professional"
medium format (2inch x 3inch negative) and large
format (4inch x 5inch negative) worlds, there
are many cameras and digital backs available.
Plan on investing, at a minimum, $10K to get
started; some digital backs run $50K to $100K.
I seriously question the long-term of any semiconductor electronics built today.
I agree entirely with your concern, but I'm not
so worried myself. Most semiconductor failures
(other than those caused by overvoltage/overcurrent/overtemperature conditions, which are not "normal operation") are
packaging failures. e.g. the hermetic seal on
breaks and contaminants leak in, physical stress disturbs the wire bonds, etc. Closely related are
impurities that were introduced during manufacturing.
In my experience, quality control has increased greatly in the semiconductor industry since the
early 70's. It's not just the production environment which has improved, it's knowledge about the overall process (including testing
and burn-in) that has advanced. The regimens
that were being applied to mil-spec parts in the
70's have been greatly improved and are applied
to consumer-grade parts today, in quantities of
billions of units.
I agree that at some point the scaling/geometry issues and radiation tolerance begin to become
the dominant factor. But IMHO we aren't at that
point yet; packaging failures still dominate.
Mistake: Using the words Flash and Embedded in the article title.
Problem 1: Flash is a very common kind of
memory chip used in embedded devices. In fact,
it's a multi-billion dollar industry. And
it has nothing to do with Shockwave or
Macromedia.
Problem 2: There's no embedded computer in the
example - it's a Windows box.
Why doesn't the Alpha matter anymore?
on
AMD's 64-Bit Chip
·
· Score: 2
Over a decade ago, DEC was selling servers and
desktop boxes based on the 64-bit Alpha architecture. They succesfully sold OS's,
compilers, and applications that ran on these
machines and took advantage of the 64-bit
architecture. Heck, Microsoft sold 64-bit
software for Alphas.
Yet the Alpha seems to be forced into complete
non-relevance by the mass media. (Witness the
Wired article, where it's not even mentioned.)
Is the Alpha really that irrelevant? Is the
experience gained (both technically *and*
marketing-wise) to be tossed and never thought
of again?
What if someone gets angry and decides to fork the project?
Maybe the GPL isn't for you. You don't have
to be angry to "fork the project"; anyone can
do anything they want with the source code, as
long as they follow the GPL license.
You don't have to use the GPL, unless you're
already using GPL'ed code in your project. The last thing a GPL'ed project needs is a
whiny controller who insists that those
who disagree with his vision are angry.
I just saw the trailer for the movie, and
my impression (given the the little snippets
that were played) was that it was a spoof of
the whole "Crop Circle" fad. A lot like the
parody episodes that X-Files would run once
or twice a season. Was I wrong?
Of course, I'm the kind who confuses Close Encounters of the Third Kind with Closet Encounters of the Nerd Kind (a wonderful spoof
of the other) while watching them to the point
that it doesn't matter which one I'm watching - I'm waiting for the singing pastries:-)
Tied/Magical Array/Hash Elements Do Not Autovivify
I never liked autovivified hash elements in the
first place. It's such a pain in the butt to put a
if (exists $hash{index}) before trying
to access everything if I don't want autovivification. Don't take this as a slam
against Perl, I love the language and the concepts, but there are a couple little nooks and
crannies that ought to somehow be fixed. I say
"somehow" because to do it with backwards compatiblity may be impossible.
Will unleashing all these tools on folks who've
never dealt with anything more structured than
point-and-drool tools like Frontpage really result in better web sites?
I'm sure it'll result in more complicated websites that are
maintained by undocumented Perl scripts. It'll probably result in
security holes via the scripts too, despite the
effort put into taint mode.
Most importantly, will there be any net gain
in design and usability? I realize that there
are learning curves with all scripting/automation
tools; the realization that automation may be
applied to a previously point-and-drool editing
task is, I'm sure, a huge step forward for most
organizations. I don't pretend to be at the top
of that learning curve myself; I'm just far enough
up it that I look back at projects I did a few
months ago and I want to hide my head in shame
because of the little thought I put into design
and usability when I did them.
I understand that developing aircraft is not a
cheap business - but the BBC news article says
the test model, an unpowered but presumably
remote-controlled glider, cost $80Million.
I'm sure lots of slick technology went into the
test article, but I gotta ask: how could a glider
cost $80Million?
(The rocket launch was valued at $7Million, BTW.)
Too many systems try to be reliable by adding
complexity. Putting on a backup system, or
two backup systems, or adding a lot of layers
of machines, or a lot of layers of software, often
gets you in trouble. Especially when you
don't know what you're doing.
Example: the system I support is mission-critical.
If it crashes, it makes the front page of the
newspaper the next day. Hundreds of thousands
of folks may get delayed by ten or fifteen
minutes or a half-hour. The system is finally
up to 99.995% availability. And how? By
turning off all the backup systems and disentangling all the horrendous software kludges
that were put in for the backup system. While the organization was trying to support hot-backup
availability, it was crashing every other day. Outside consultants blamed this on flaky hardware and said the system had a life of, at most, a
year and a half. Here we are now, four years
later, and reliability is better than ever:-).
I like to think that some of the work, and (even
better) some of my attitudes have helped get us
where we are.
In order to complete this, a set of
regression tests were written.
That's not really regression testing. Regression
testing is making sure something that used to
work still works; this is done by running
tests that were originally done to qualify
the original software.
If you don't have any test results from the "before" system, you cannot compare them with
test results from the "after" system. And without
such a comparison, you are not regression testing.
The one example test you describe is more of
an internal-consistency-error-handler check. These are
important too, of course. Perhaps the most
difficult part of internal-consistency-error-handler
testing is that you have to cause an internal
inconsistency to test the error-handling code.
Perl was not designed to do what it's now being used for.
A tool that is "top-down" spec'ed, analyzed, and
designed will be good for exactly what it was
defined for. Perl has grown in ways that such
a designed language never could.
To me, the true mark of success for a tool is
that it gets used for all sorts of things for
which it was not designed.
In this way, Perl is the biggest success story
of all time.
The result is an awfully designed language made of layers
and layers of incoherent stuff.
It has been cleaned up, slowly. It has wonderful
OO techniques available (although they probably
do not appeal to anyone who believes that C++
is "object oriented"). The worst punctuation-based built-ins now have symbolic
names. But yes, it is kinda messy, in a way
very similar to English.
Well-designed human languages (e.g. Esperanto)
don't fare too well in comparison to the ugly
mess ones, either:-)
Yet another bozo on the bus of folks who
think that Perl is only good for CGI.
IMHO Perl will be quite useful long after
the web is as obsolete as Gopher. Perl is not
just a language, and it's not just for web
content; it's a very general and powerful way
for thinking about and solving problems.
Now that fiber is here, these advanced copper versions seem silly
Why does everyone keep talking like fiber is new?
It was very available 20 years ago and didn't
replace copper (which was 10Mbit/sec thicknet -
try pulling a few hundred feet of *that*)
then. It won't replace copper now, especially
since copper is even more convenient, durable, and
cross-compatible. They both
will continue to be used where appropriate.
Slashdot Mirror
The difficulty is in this first step. It's not like you can go to the hardware store and buy an "entropymeter" like you can a voltmeter or thermometer. So how do you measure entropy? i.e. how do you look for patterns in data when you might not even understand the process that creates the data? We do have some tools (heck, I like bzipping the original and comparing compressed with uncompressed file sizes) but they do not find all relevant patterns by any means.
I'm not saying that entropy is a useless concept; I'm just saying that it's not an easy thing to measure in complex (AI-type) systems. When your tool fails to detect a pattern it will increase your measured entropy, but the pattern is still there. I am extremely unconfortable if changing my tool changes my measure of the entropy.
I get the impression from your rejection of load balancing that you are more typically on the "client" rather than the "server" end of a connection. (Or maybe you're a server with only a single client, in which case load balancing probably doesn't help either.)
If you're a guy in his house who wants a fatter pipe to download single big files, you probably cannot get the folks at the server to install special equipment for you. If your ISP will help you to support aggregation by putting equipment on their end to hook into their upstream connection, that's not so bad, and some small regional ISP's do specialize in this. But you'll have to tell us where you are to get a recommendation for such ISP's.
Others might quibble about testing the existing (small) hard drives, floppy drive, and CD-ROM, but I'd just count on trashing these items. They're cheap and plentiful new. Besides, if you're buying massive numbers of machines to administer in a giant cluster, you probably don't need or want any removable media on each machine.
Same goes for whatever existing motherboards might be in the machines. If they're a couple years old you'd probably have to go hunting around the net to find BIOS updates etc. to make them work with your peripherals. It's not worth the time, especially with decent new motherboards available for a half-hour's pay.
I don't know the number, but the trend is disturbing. I would have naively thought that as
- computers get more and more computational power
- while their power requirements per computational power decrease
that the number of computers needed would decrease. Instead, the number of computers seem to be multiplying. Even I'm guilty of it; add a firewall here, add a web server there, add a NAS box in the room.I do appreciate your desire for a low-power consumption box. And I do appreciate that your computing solution only involves a single box. Good luck in your search.
Almost all of these were uttered in that Google thread from 1985 about Y2K :-)
Strangely, though, few seem to care that there are many file formats where the "automatic" kernel 64-bit date expansion they expect will be a problem. If the application expects that the date will always fit in that 32-bit field, and there's no obvious way to extend that field, then you have a lot of files which may no longer be useful...
The thing is, network security weaknesses are rarely accidental. You can reliably predict the top five causes of security weaknesses:
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
- Buffer overflows
There's nothing at all accidental about why those are where the security weaknesses are - it's because most services are written in languages that make it very easy to overflow a buffer. What we need is a law that makes it a crime to do such poor software engineering.It won't affect me much, as my systems are all built from sources. And most of the tools that can potentially do jpegs can be built without jpeg support. But it's sad to hear that users of binary Linux distros may be hurt by this.
It's clear that Forgent is going after companies that develop browsers, sell image editing tools, etc., but on your typical Unix/Linux platform these tools often are "just" linked to libjpeg where the real encoding and decoding is done. In this case might they try to go after anyone whose name appears in the libjpeg sources? Ack!
The problem for you is that your cameras probably do not have interchangable backs. There are very few 35mm cameras that have interchangeable or digital backs; see this web page for an example that does. In the "professional" medium format (2inch x 3inch negative) and large format (4inch x 5inch negative) worlds, there are many cameras and digital backs available. Plan on investing, at a minimum, $10K to get started; some digital backs run $50K to $100K.
I agree entirely with your concern, but I'm not so worried myself. Most semiconductor failures (other than those caused by overvoltage/overcurrent/overtemperature conditions, which are not "normal operation") are packaging failures. e.g. the hermetic seal on breaks and contaminants leak in, physical stress disturbs the wire bonds, etc. Closely related are impurities that were introduced during manufacturing.
In my experience, quality control has increased greatly in the semiconductor industry since the early 70's. It's not just the production environment which has improved, it's knowledge about the overall process (including testing and burn-in) that has advanced. The regimens that were being applied to mil-spec parts in the 70's have been greatly improved and are applied to consumer-grade parts today, in quantities of billions of units.
I agree that at some point the scaling/geometry issues and radiation tolerance begin to become the dominant factor. But IMHO we aren't at that point yet; packaging failures still dominate.
Problem 1: Flash is a very common kind of memory chip used in embedded devices. In fact, it's a multi-billion dollar industry. And it has nothing to do with Shockwave or Macromedia.
Problem 2: There's no embedded computer in the example - it's a Windows box.
Yet the Alpha seems to be forced into complete non-relevance by the mass media. (Witness the Wired article, where it's not even mentioned.) Is the Alpha really that irrelevant? Is the experience gained (both technically *and* marketing-wise) to be tossed and never thought of again?
Maybe the GPL isn't for you. You don't have to be angry to "fork the project"; anyone can do anything they want with the source code, as long as they follow the GPL license.
You don't have to use the GPL, unless you're already using GPL'ed code in your project. The last thing a GPL'ed project needs is a whiny controller who insists that those who disagree with his vision are angry.
Of course, I'm the kind who confuses Close Encounters of the Third Kind with Closet Encounters of the Nerd Kind (a wonderful spoof of the other) while watching them to the point that it doesn't matter which one I'm watching - I'm waiting for the singing pastries :-)
I never liked autovivified hash elements in the first place. It's such a pain in the butt to put a if (exists $hash{index}) before trying to access everything if I don't want autovivification. Don't take this as a slam against Perl, I love the language and the concepts, but there are a couple little nooks and crannies that ought to somehow be fixed. I say "somehow" because to do it with backwards compatiblity may be impossible.
I'm sure it'll result in more complicated websites that are maintained by undocumented Perl scripts. It'll probably result in security holes via the scripts too, despite the effort put into taint mode.
Most importantly, will there be any net gain in design and usability? I realize that there are learning curves with all scripting/automation tools; the realization that automation may be applied to a previously point-and-drool editing task is, I'm sure, a huge step forward for most organizations. I don't pretend to be at the top of that learning curve myself; I'm just far enough up it that I look back at projects I did a few months ago and I want to hide my head in shame because of the little thought I put into design and usability when I did them.
I understand that developing aircraft is not a cheap business - but the BBC news article says the test model, an unpowered but presumably remote-controlled glider, cost $80Million. I'm sure lots of slick technology went into the test article, but I gotta ask: how could a glider cost $80Million? (The rocket launch was valued at $7Million, BTW.)
Not a single one was succesful, of course :-)
Example: the system I support is mission-critical. If it crashes, it makes the front page of the newspaper the next day. Hundreds of thousands of folks may get delayed by ten or fifteen minutes or a half-hour. The system is finally up to 99.995% availability. And how? By turning off all the backup systems and disentangling all the horrendous software kludges that were put in for the backup system. While the organization was trying to support hot-backup availability, it was crashing every other day. Outside consultants blamed this on flaky hardware and said the system had a life of, at most, a year and a half. Here we are now, four years later, and reliability is better than ever :-).
I like to think that some of the work, and (even
better) some of my attitudes have helped get us
where we are.
In order to complete this, a set of regression tests were written.
That's not really regression testing. Regression testing is making sure something that used to work still works; this is done by running tests that were originally done to qualify the original software.
If you don't have any test results from the "before" system, you cannot compare them with test results from the "after" system. And without such a comparison, you are not regression testing.
The one example test you describe is more of an internal-consistency-error-handler check. These are important too, of course. Perhaps the most difficult part of internal-consistency-error-handler testing is that you have to cause an internal inconsistency to test the error-handling code.
A tool that is "top-down" spec'ed, analyzed, and designed will be good for exactly what it was defined for. Perl has grown in ways that such a designed language never could.
To me, the true mark of success for a tool is that it gets used for all sorts of things for which it was not designed. In this way, Perl is the biggest success story of all time.
The result is an awfully designed language made of layers and layers of incoherent stuff.
It has been cleaned up, slowly. It has wonderful OO techniques available (although they probably do not appeal to anyone who believes that C++ is "object oriented"). The worst punctuation-based built-ins now have symbolic names. But yes, it is kinda messy, in a way very similar to English.
Well-designed human languages (e.g. Esperanto) don't fare too well in comparison to the ugly mess ones, either :-)
Yet another bozo on the bus of folks who think that Perl is only good for CGI.
IMHO Perl will be quite useful long after the web is as obsolete as Gopher. Perl is not just a language, and it's not just for web content; it's a very general and powerful way for thinking about and solving problems.
Why does everyone keep talking like fiber is new? It was very available 20 years ago and didn't replace copper (which was 10Mbit/sec thicknet - try pulling a few hundred feet of *that*) then. It won't replace copper now, especially since copper is even more convenient, durable, and cross-compatible. They both will continue to be used where appropriate.