building ramshackle systems out of used and discarded first world computer
parts.
Isn't this the same topic that about a quarter
of the "Ask Slashdot" threads are about?:-)
Interesting to see that lead is now a horribly
toxic substance, at least to the BBC reporter.
When I was a kid we played with mercury with
few precautions, and all fishing line weights
were lead.
The pictures are pure photojournalism hype at
its worst. Yeah, let's put some kid in front
of that pile of junk and have them make a face!
I think you really want a good scientific calculator. When I was in grad school something
like a HP-48 met all your needs, and that was
ten years ago. I'm not sure what's available
now (I'm at a point in my career where everything
is done either on the back of an envelope or
on a supercomputer and there's very little middle ground), but I'm sure that something
is. If worse comes to worse, buy an old HP-48!
All they need to add is "currently in production" or "commercially available". Even that last one
is barely true; the Atlas V wouldn't exist if not for
military customers.
Considering when I was last with Telstra they didn't even offer support for Linux with their broadband offerings, I can't
imagine this will really come to much
AOL doesn't offer Linux service (much less support) to their customers, yet their internal
network has thousands of Linux boxes and every
day I get AOL job announcements looking for
Linux, Perl, and MySQL workers. I don't really
expect the "front end" to look like the "back
end", though I certainly do not have an AOL
account!
Copyrighting all phone numbers as music
on
Haiku vs Spam
·
· Score: 2
There was an outfit in Australia or New
Zealand a few years ago that was going to
generate all the touch-tones that form phone
numbers (billions of 'em) and register them with
the copyright office. Then they were gonna take
folks with phones and deep pockets to court, suing them for using their copyrighted
"music" without permission.
See the story here. I'm guessing that their plans fell through.
Seeing continued OS-level design flaws in
Microsoft products is, to me, reassuring. When
MS goes ahead with Palladium I'm now quite
confident that it will be riddled with fundamental
design flaws that will make its "security" (read: capitalist totalitarianism rule over the masses) a joke.
What good is a 1 TFLOP CPU if you don't
have a memory bus to support it? The mark
of a true supercomputer is not CPU power, but
truly massive memory bandwidth. (Low-latency
memory doesn't hurt, but for big vector problems
it doesn't always help.)
Caches help for little problems, but you don't
put a 1 TFLOP CPU onto a little problem.
My reference to low standards was not meant to refer to the application level. I meant, why were they ever tolerated at the
compiler / interpreter level?
It's an attitude thing.
Your classical C
programmer regards memory management as something
too important for the compiler to take care of.
OTOH your classical Perl programmer regards memory management as too important for the programmer to take care of.
So, who's going to develop a compiler/interpreter that prevents buffer overflows?
There are several languages in wide use today where the most idiomatic way to handle strings is
immune to buffer overflows. Perl, for example. The worst a buffer-overflow attacker could do against a well-written Perl service is cause the
network service to run out of memory and die. Admittedly that is a kind of denial-of-service attack, but it's not the worse
thing that could happen.
And I'm sure that a
dedicated C programmer could write a Perl program
that would be vulnerable to buffer overflows, but only if he departed from "idiomatic Perl" and
lapsed back into his bad C habits. Sort-of a
variation of "A good Fortran programmer can write
spaghetti code in any language!".
But even Perl is no magic bullet. Fix the
buffer overflow problem and then the attackers
start chiseling away at other stuff, like file
race conditions. In the end, there's no substitute for solid software engineering.
For that matter, who set the standard so low that buffer overflows were ever tolerated?
Simple economics. It mostly works, no we didn't
test every boundary condition, but the way we wrote it such testing/verification would be impossible, so ship it.
I know that many people will lash out at these sort of ideas, but as long as there are strict distinctions between "professional"
and "non-professional", everyone should be able to get their way. Hobbyists can still do everything they want, while Software
PE's can develop commercial software in the same way as building contractors develop office complexes
The thing is, it's the professionals who have
been doing it "the unsafe way" for years who will
keep on doing the same thing. It's the upstart
hobbyists who have a reliable set of utilities
that are much more immune to buffer overflows.
Just as an example, on all commercial Unices that I've had a chance to play with I've been able to make the 'pwd' command dump core. The GNU 'pwd' has never dumped core on me, despite my attempts.
The scary thing is, 'pwd' is perhaps one of the simplest shell commands there is. It takes no
arguments. Yet it still took many years before
the GNU one became as refined as it is today.
Compare that to your typical network service
and it's nightmare time. How many security patches have there been for vixie-cron? wu-ftpd?
Those are relatively simple things!
No language is going to be able to force a programmer to not do stupid things, but things like
perl 'taint' mode do help a little. Even then you
have to worry about file race conditions in some
circumstances.
The 2006 cutoff date isn't new, although the
FCC has backed off somewhat from their original
very aggressive plan, which would have banned
analog transmissions on that date. See this Usenet
thread from 1997 to see my initial reaction to
*that* proposal.
To sum it up, there's an artificial "bandwidth shortage" combined with a desire by electronics
manufacturers to sell more expensive stuff. Get
those groups lobbying the FCC and the result seems
pretty obvious to me.
Re:Why doesn't the Alpha matter anymore?
on
AMD's 64-Bit Chip
·
· Score: 2
Well, DEC's biggest problem was selling the Alpha.
I agree, they had a problem selling them. Compaq
certainly didn't have a clue about marketing
anything other than PC-clones, and the DEC
organization didn't do as well as they
should have either. The Itanic was pointed
to as killing Alpha sales, even when the Itanic
was vaporware that was 5 years off, and even today Itanic sales
volumes don't begin to approach Alpha sales. That's why I want to know: Why doesn't
anyone look at DEC's marketing experience?. As a warning of what not
to do, if nothing else:-).
but you can't take an 8080 binary and run it on any x86 processor
Almost. The Japanese company NEC sold 80x86
compatible processors called the V20 and V30 which
also had an 8080 binary compatibility mode
built-in.
The V20 and V30 were not
"x86 processors" (the number 86 isn't in the
part name!) so you are technically correct, but
the V20 and V30 were, in spirit and in PC-clone
applications, treated as x86 compatibles.
Dual-ported disk drives are nothing new; they've
been around in many forms since the 70's (SMD),
80's (DEC SDI), and up through today (SCSI has
supported multiple initiators since it graduated
from SASI in the mid-80's.)
Of course, most of the older drives also had
prominent lights and pushbuttons on the front
that let you write-protect the drive, in some
cases on a per-port basis.
What has often been missing is OS support for
dual-ported drives; the lack of support is most conspicuous
today. As a result most modern OS's trying to use
a dual ported drive will have to "take its
turn" having the disk mounted if there's
any possiblity the other machine is going
to do a write. If the OS
doesn't even support the simple concepts of
mount and dismount, then you probably cannot
use it at all!
So far, what Real has shown is marketing hype.
There is no open source software
until they give us the source. And as Bruce
and others have pointed out, they're only
open-sourcing Microsoft's codecs, not their
own; this is not the spirit nor the letter
of open-source!
Power Tools for Power Fools is what I'm worried about. If they're producing bad web pages by
hand, they'll probably produce many more bad web
pages by scripts.
Maybe I'm being too pessimistic: After all,
there are real opportunities to introduce
architecture, design, and maintainability through
Perl scripts (or whatever your favorite automation
tool is). And Perl is one of the best tools
to use - its built in data structures (especially
hashes and hashes tied to DB's) put it near the
top of the heap for teaching design issues. PHP
has similar elegance though maybe less generality.
I hope this book not only exposes
point-and-drool HTML makers to the automation
possibilities, but that it also forces them to think
about these bigger issues. Even something as
trivial as forcing someone to think about what
a unique key for database access should be is a
huge education for too many in the web business.
Could you reccomend some books to those folks that are interested in not becomming a bad programmer
You have to qualify what you mean by "programmer":
Is someone going to hand you a detailed design which you then translate into code? In this case, just about any of the "programming xxx" books on the shelves at the bookstore will do fine.
Or are you
responsible for analysis, architecture and design too? Will you be responsible for maintaining the databases? Will you interface to other systems? If so, try to take some courses or read books on architecture and design. If web
pages are part of the medium, look carefully
at the processes involved at other "good" succesful websites.
And don't ignore the failures either. Read the
RISKS Digest and
Web Pages that Suck, too.
An example of a much more refined version of this
technique, Visualroute,
not only attempts to tell you where the IP address
is, but it also gives you a geographic map of a
traceroute to that address. Yes, occasionally
it goofs up, but it's really pretty good overall. And it's been around since the late 90's.
There are similar freeware/government/.edu developed tools floating around since the mid-90's, too. I seem to recall one from one of the national labs, LLNL or LBL? Many are mentioned in this Google Search.
It's been years since I monitored them, but
UUCP Maps were common in the 80's. These generally are not IP, but they do show that
folks were relating geographic locations to
addresses a couple of decades ago.
Problems are legal, not technical
on
Digital Dark Ages?
·
· Score: 5, Interesting
Where legal permission to preserve old data
has been obtained, lots of interesting stuff
has been saved. Examples that I'm personally
involved with:
The PDP-10 Software Archive. Hundreds of tapes
from the 60's, 70's, and 80's have been rescued
with sources and documentation for the systems on
which the ARPAnet was built.
The Unix Heritage Society collection. Again, source
code, data, and documentation that are all vitally
important.
But the only reason these archives can be built
and maintained is that it is legal to do so, thanks
to the hard work of preservationists like
Bob Supnik (see his SIMH "old iron" simulation packages) and Warren Toomey who have secured
such licenses. Without such permission, many other archives
of historical software that I've assembled myself
cannot be distributed to the rest of the world.
C++ has lousy run-time type information.
Perl lets you interrogate a class's
structure and capabilities at run-time: class
name, hierarchical relationships, and
method compatibility. (I'm mostly quoting
from Conway's book here.)
If you've always been wearing the C++ strait
jacket, you might not know how much you're
missing by not having dynamic class reassignment
and dynamic inheritance. Other OO languages
(like Smalltalk) have similar dynamic qualities.
It depends on your programming style - you may
actually like the restrictive C++ way. I don't.
A lot of the things where you have to sweat to
make multiple inheritance work in C++ come very
naturally in OO Perl.
I agree, Perl OO is not the same as C++ or Java
OO. It does typify TIMTOWTDI. Perl OO's
use of Perl's built-in hashes and calling
flexibility (especially run-time redirection)
is what makes it wonderful; you seem to feel
differently.
good book written for Perl about how to effectively use all the modules in CPAN.
CPAN is amazingly useful, and (thank god) stops
folks from re-inventing the wheel all day long.
It's a core strength of Perl.
Christiansen's _Perl Cookbook_ is a start,
especially for the bread-and-butter CPAN stuff. But
all the modules in CPAN? That's
a lot! There are (at this moment) 3454 such
modules! I think it's better to train people
to think to themselves Somebody else must've
solved this problem before. I'll look in CPAN
for the solution and let them do the looking
themselves.
While I don't have numbers, I think you'll find zShops is more popular than you think.
I agree, it's not bad.
And my wife, who runs a bookstore, tells me that her store lists their collectable stuff on Amazon and does well
with it.
And yes, Amazon has got a great thing going
with used books/CD's.
Despite the fact that searching works so much
better on Amazon than on Ebay, when I've listed
similar items on both I notice a lot more
viewers (looking at my webserver log for image
access) on Ebay than on Amazon. You've got a
good point: maybe the search mechanisms on
Ebay are so bad that folks look at everything
whether they're serious about buying or not.
I thought the date on the Microsoft OS box was
the expiration date, just like on canned and
boxed food.
e.g. Win 98 went bad in
1998, etc.
Re:Great Now Paypal will be as useless as EBAY PAY
on
Ebay buys PayPal
·
· Score: 3, Interesting
Ebay Payment is substandard.
I disagree. For Ebay payments buyers you don't have
to go through the Paypal "registration"
process (where they try to persuade you to
upgrade to Premier where they get your bank account
information), and for Ebay payment sellers you get
deposit straight to your bank account without
sitting around in a namby-pamby "paypal" account
first.
Both systems did have strong discouraging factors
for non-US buyers, but things have gotten better
for both sides in the past couple of years.
Ebay payments did always have a larger
seller fee than Paypal, though.
I thought the Amazon "Zshops" system was pretty
cool for both buyers and sellers. The nice
thing about it is that it worked for non-auction
sales *and* it didn't require an extensive
registration process like Paypal. But it appears to have never really
become popular with users.
Lots of debugging techniques don't work well
with threaded programs. I think that blame here
lies not with gprof, but with the
threaded-programming paradigm or its current
implementations.
The problems that threading solves (multiple
outstanding I/O's, multiple CPU utilization) can
be solved using other methods. Those other
methods have their evils, too, but trading
off for the lesser net evil is what design and
analysis is all about.
Lack of profiling tools
is pretty far down on the list of tradeoffs,
in my opinion; much higher up are issues of
maintainability and portability, areas where
threading does badly anyway.
Slashdot Mirror
Isn't this the same topic that about a quarter of the "Ask Slashdot" threads are about? :-)
Interesting to see that lead is now a horribly toxic substance, at least to the BBC reporter. When I was a kid we played with mercury with few precautions, and all fishing line weights were lead.
The pictures are pure photojournalism hype at its worst. Yeah, let's put some kid in front of that pile of junk and have them make a face!
I think you really want a good scientific calculator. When I was in grad school something like a HP-48 met all your needs, and that was ten years ago. I'm not sure what's available now (I'm at a point in my career where everything is done either on the back of an envelope or on a supercomputer and there's very little middle ground), but I'm sure that something is. If worse comes to worse, buy an old HP-48!
All they need to add is "currently in production" or "commercially available". Even that last one is barely true; the Atlas V wouldn't exist if not for military customers.
AOL doesn't offer Linux service (much less support) to their customers, yet their internal network has thousands of Linux boxes and every day I get AOL job announcements looking for Linux, Perl, and MySQL workers. I don't really expect the "front end" to look like the "back end", though I certainly do not have an AOL account!
See the story here. I'm guessing that their plans fell through.
Seeing continued OS-level design flaws in Microsoft products is, to me, reassuring. When MS goes ahead with Palladium I'm now quite confident that it will be riddled with fundamental design flaws that will make its "security" (read: capitalist totalitarianism rule over the masses) a joke.
Caches help for little problems, but you don't put a 1 TFLOP CPU onto a little problem.
It's an attitude thing.
Your classical C programmer regards memory management as something too important for the compiler to take care of.
OTOH your classical Perl programmer regards memory management as too important for the programmer to take care of.
There are several languages in wide use today where the most idiomatic way to handle strings is immune to buffer overflows. Perl, for example. The worst a buffer-overflow attacker could do against a well-written Perl service is cause the network service to run out of memory and die. Admittedly that is a kind of denial-of-service attack, but it's not the worse thing that could happen.
And I'm sure that a dedicated C programmer could write a Perl program that would be vulnerable to buffer overflows, but only if he departed from "idiomatic Perl" and lapsed back into his bad C habits. Sort-of a variation of "A good Fortran programmer can write spaghetti code in any language!".
But even Perl is no magic bullet. Fix the buffer overflow problem and then the attackers start chiseling away at other stuff, like file race conditions. In the end, there's no substitute for solid software engineering.
For that matter, who set the standard so low that buffer overflows were ever tolerated?
Simple economics. It mostly works, no we didn't test every boundary condition, but the way we wrote it such testing/verification would be impossible, so ship it.
The thing is, it's the professionals who have been doing it "the unsafe way" for years who will keep on doing the same thing. It's the upstart hobbyists who have a reliable set of utilities that are much more immune to buffer overflows.
Just as an example, on all commercial Unices that I've had a chance to play with I've been able to make the 'pwd' command dump core. The GNU 'pwd' has never dumped core on me, despite my attempts.
The scary thing is, 'pwd' is perhaps one of the simplest shell commands there is. It takes no arguments. Yet it still took many years before the GNU one became as refined as it is today. Compare that to your typical network service and it's nightmare time. How many security patches have there been for vixie-cron? wu-ftpd? Those are relatively simple things!
No language is going to be able to force a programmer to not do stupid things, but things like perl 'taint' mode do help a little. Even then you have to worry about file race conditions in some circumstances.
To sum it up, there's an artificial "bandwidth shortage" combined with a desire by electronics manufacturers to sell more expensive stuff. Get those groups lobbying the FCC and the result seems pretty obvious to me.
I agree, they had a problem selling them. Compaq certainly didn't have a clue about marketing anything other than PC-clones, and the DEC organization didn't do as well as they should have either. The Itanic was pointed to as killing Alpha sales, even when the Itanic was vaporware that was 5 years off, and even today Itanic sales volumes don't begin to approach Alpha sales. That's why I want to know: Why doesn't anyone look at DEC's marketing experience?. As a warning of what not to do, if nothing else :-).
Almost. The Japanese company NEC sold 80x86 compatible processors called the V20 and V30 which also had an 8080 binary compatibility mode built-in.
The V20 and V30 were not "x86 processors" (the number 86 isn't in the part name!) so you are technically correct, but the V20 and V30 were, in spirit and in PC-clone applications, treated as x86 compatibles.
Of course, most of the older drives also had prominent lights and pushbuttons on the front that let you write-protect the drive, in some cases on a per-port basis.
What has often been missing is OS support for dual-ported drives; the lack of support is most conspicuous today. As a result most modern OS's trying to use a dual ported drive will have to "take its turn" having the disk mounted if there's any possiblity the other machine is going to do a write. If the OS doesn't even support the simple concepts of mount and dismount, then you probably cannot use it at all!
So far, what Real has shown is marketing hype. There is no open source software until they give us the source. And as Bruce and others have pointed out, they're only open-sourcing Microsoft's codecs, not their own; this is not the spirit nor the letter of open-source!
Maybe I'm being too pessimistic: After all, there are real opportunities to introduce architecture, design, and maintainability through Perl scripts (or whatever your favorite automation tool is). And Perl is one of the best tools to use - its built in data structures (especially hashes and hashes tied to DB's) put it near the top of the heap for teaching design issues. PHP has similar elegance though maybe less generality. I hope this book not only exposes point-and-drool HTML makers to the automation possibilities, but that it also forces them to think about these bigger issues. Even something as trivial as forcing someone to think about what a unique key for database access should be is a huge education for too many in the web business.
You have to qualify what you mean by "programmer":
- Is someone going to hand you a detailed design which you then translate into code? In this case, just about any of the "programming xxx" books on the shelves at the bookstore will do fine.
- Or are you
responsible for analysis, architecture and design too? Will you be responsible for maintaining the databases? Will you interface to other systems? If so, try to take some courses or read books on architecture and design. If web
pages are part of the medium, look carefully
at the processes involved at other "good" succesful websites.
And don't ignore the failures either. Read the RISKS Digest and Web Pages that Suck, too.There are similar freeware/government/.edu developed tools floating around since the mid-90's, too. I seem to recall one from one of the national labs, LLNL or LBL? Many are mentioned in this Google Search.
It's been years since I monitored them, but UUCP Maps were common in the 80's. These generally are not IP, but they do show that folks were relating geographic locations to addresses a couple of decades ago.
But the only reason these archives can be built and maintained is that it is legal to do so, thanks to the hard work of preservationists like Bob Supnik (see his SIMH "old iron" simulation packages) and Warren Toomey who have secured such licenses. Without such permission, many other archives of historical software that I've assembled myself cannot be distributed to the rest of the world.
If you've always been wearing the C++ strait jacket, you might not know how much you're missing by not having dynamic class reassignment and dynamic inheritance. Other OO languages (like Smalltalk) have similar dynamic qualities.
It depends on your programming style - you may actually like the restrictive C++ way. I don't. A lot of the things where you have to sweat to make multiple inheritance work in C++ come very naturally in OO Perl.
I agree, Perl OO is not the same as C++ or Java OO. It does typify TIMTOWTDI. Perl OO's use of Perl's built-in hashes and calling flexibility (especially run-time redirection) is what makes it wonderful; you seem to feel differently.
good book written for Perl about how to effectively use all the modules in CPAN.
CPAN is amazingly useful, and (thank god) stops folks from re-inventing the wheel all day long. It's a core strength of Perl.
Christiansen's _Perl Cookbook_ is a start, especially for the bread-and-butter CPAN stuff. But all the modules in CPAN? That's a lot! There are (at this moment) 3454 such modules! I think it's better to train people to think to themselves Somebody else must've solved this problem before. I'll look in CPAN for the solution and let them do the looking themselves.
I agree, it's not bad.
And my wife, who runs a bookstore, tells me that her store lists their collectable stuff on Amazon and does well with it.
And yes, Amazon has got a great thing going with used books/CD's.
Despite the fact that searching works so much better on Amazon than on Ebay, when I've listed similar items on both I notice a lot more viewers (looking at my webserver log for image access) on Ebay than on Amazon. You've got a good point: maybe the search mechanisms on Ebay are so bad that folks look at everything whether they're serious about buying or not.
e.g. Win 98 went bad in 1998, etc.
I disagree. For Ebay payments buyers you don't have to go through the Paypal "registration" process (where they try to persuade you to upgrade to Premier where they get your bank account information), and for Ebay payment sellers you get deposit straight to your bank account without sitting around in a namby-pamby "paypal" account first.
Both systems did have strong discouraging factors for non-US buyers, but things have gotten better for both sides in the past couple of years.
Ebay payments did always have a larger seller fee than Paypal, though.
I thought the Amazon "Zshops" system was pretty cool for both buyers and sellers. The nice thing about it is that it worked for non-auction sales *and* it didn't require an extensive registration process like Paypal. But it appears to have never really become popular with users.
The problems that threading solves (multiple outstanding I/O's, multiple CPU utilization) can be solved using other methods. Those other methods have their evils, too, but trading off for the lesser net evil is what design and analysis is all about.
Lack of profiling tools is pretty far down on the list of tradeoffs, in my opinion; much higher up are issues of maintainability and portability, areas where threading does badly anyway.