Bikes with shaft drive have been built, but the shaft was too heavy. That idea might be worth a try again. It wiil never be as light as a chain, but with newer materials, it would be better than the 1940s steel shaft drive bikes. It could be useful for riding through brush and grass, where chains jam.
As for transmission bikes, the old three-speed bikes had that decades ago. There was even a Borg-Warner 2-speed automatic tranmission for bikes.
Berg makes flexible plastic chain, and at one time they tried selling a version for bikes. It turned out to have compatibility problems with existing sprockets, but it could work with a sprocket redesign. Berg chain was used on the Gossamer Condor ultralight; it's lighter than steel chain.
So that's something with potential.
I once came across a study guide for the exam for New York City Subway Change Booth Attendant. It wasn't a joke. NYC fills civil service jobs by competitive examination.
There were questions like "If a rider wanted to get from 34th St and Lexington to Junction Boulevard in Queens, they should 1) take the Lexington Avenue uptown local to...".
NYC had to dumb down the tests, though, to avoid charges of racial discrimination. Now they're pass/fail, and those who pass are selected in sequence. They used to be truly competitive, resulting in overqualified low-level people.
Also in that set was the 1956 test for U.S. State Department Foreign Service Officer. "Which of the following phrases best expresses the idea that the United States supports the government with which you are dealing but will not support them militarily".
Go to Edit->Fill In Form in Mozilla and watch what happens.
You may be surprised how much of your personal information Mozilla has been quietly collecting by watching your web browsing. Has it captured your driver's license number or credit card numbers or mother's maiden name yet? Check and see.
AOL lost money for six years and hid it with funny accounting until the SEC caught them. They were treating those giveaway AOL disks as a capital expense. Really.
Now they're in decline. Why would anyone want to acquire them, except as a distressed company? Their "content"? Yeah, right.
There was once a fad for making C look like Pascal using defines. Didn't help.
PL/I had compile-time programmability. That didn't help.
In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.
In the early days of UNIX, the M4 macro processor was popular. (It lives on as the horrible front end to Sendmail.)
Term-rewriting systems were a fad in the mid 1980s (remember Prolog?). Didn't help.
The trouble with compile-time programmability is lack of debuggability. At least with macro processors, you can look at the output. Combined with a language like C++, which has hiding without safety, it can only lead to trouble.
As for the examples, they show loop unwinding on an RS6000. The generated code is more appropriate for an earlier model PowerPC. The RS6000 has register renaming, so it's not necessary to use a different register for each successive operation to get instruction level parallelism.
Register renaming is what made loop unrolling obsolete. In the x86 world, register renaming came in with the Pentium Pro. For x86, it's essential if you want to get much instruction level paralleism, since there are so few registers. Once that worked, it was possible to get several iterations of the same loop going at the same time.
The downside of loop unrolling is code bloat, which leads to cache misses.
Up at the source level at which Blitz is working, the unrolling template has no idea of what's going on down at the machine level. Doing a machine-level optimization at the source level can well be a lose.
I used to do some heavy number-crunching involving a code generator that unwound big mechanical engineering problems into huge blocks of straight-line C code. In 1990, this was a clear win. By 1998, it was a clear lose.
There's a group of C++ programmers who are into abusing the template mechanism into a compile-time programming environment. This is not a good thing.
The most impressive perversion of this ilk is the Blitz numeric library. This does loop unrolling by using the template library as a term-rewriting system. The resulting code is very complex, hard to debug, and of marginal value. Blindly unrollilng loops without understanding the target architecture at the instruction level is a lose on many modern superscalar machines. Newer machines tend to do loops faster than straight-line code.
Debugging compile-time processing in C++ is tough.
You can't step through the process, you can't print anything, and the compiler doesn't provides any output about what's going on. Programming at compile time has a long, sordid history (LISP macros come to mind), and C++ is an inferior environment for it anyway.
If you're using a compiler which will develop templates in-line, decide if-statements at compile time, and discard unreachable code (which includes most modern compilers), it's better to write code which works that way, rather than use template specialization.
First, if SCO stalls much longer on discovery, Cravath will be in a good position to move for a dismissal. They might get it, too. Maybe even a dismissal with prejudice, so SCO can't refile,
or summary judgement in IBM's favor.
Independent of this, it looks like IBM is gearing up for a securities-fraud counterclaim. Cravath has pointed out in legal filings that SCO has made statements publicly that are inconsistent with the positions they take in court. Ordinarily, that's OK. But when the stock price spikes and insiders are cashing out, that's not OK.
There's also the potential of a false-claim-of-copyright claim. That's rarely used, but here, it's clearly appropriate.
This is going to crank for a while, but unless SCO comes up with something a lot better than what they've shown so far, they're not going to win.
What's really happening is that control of the phone number database is moving to Verisign. Verisign runs the largest SS7 network, which handles routing and billing data for US telcos. As with the Internet, lookup and switching are now separated. Phone number lookup now works much like DNS. Verisign doesn't quite have the lock on this they have on ".com", etc., but they're getting there. Number portability will help Verisign, because if both the gaining and losing telco use Verisign, the transfer works better.
Verisign also handles wiretapping. If your phone is being wiretapped, Verisign reroutes all your calls (in and out) to a wiretapping center by altering the routing database. From the wiretapping center, the call is then routed to the destination. This allows both interception and, potentially, man-in-the-middle crypto attacks.
Surely the most overpaid job in the world is supermodel photographer.
Some photographers are worth it. Look at Richard Avedon's work.
Talk to some models. It's a lousy job. The top 50 or so make real money. All the others make less than a mid-level programmer. Below the top 500 or so, it's a part-time job with a short career. There are thousands of actress/model/waitress types in LA.
Here's the real robot hall of fame, the Computer History Museum's robot collection. Many of the famous ones are there, including the Hopkins Beast and Shakey. They used to be on public display in Boston, but now they're in Mountain View, California. The Computer History Museum now has a new building, and is gradually setting up exhibits. Tours are available.
The semiconductor industry has had periods when the fab-technology people were behind the device-physics people. In those periods, it was possible to build high-density but imperfect parts. This led to various approaches for dealing with parts with defects. Zapping bad cells with a laser or E-beam, redundant circuits, fuses blown during test to isolate dud sections, and prescans of the substrate for defects have been tried and made to work. All these techniques work, but tend to be inefficient either in terms of chip real estate or manufacturing cost.
But so far, the fab-technology people have always caught up, fixed the defect problem, and made it possible to produce perfect parts with high yields. None of those techniques have been used much in production products.
Right now, fab technology is ahead of device physics. It's possible to fabricate smaller transistors than can be made to work. Power dissipation is more of a limit than line width.
So at least on flat silicon, we don't need this yet.
On January 1, California's new anti-spam law goes into effect. This has several key features. First, the default penalty for spamming is $1000 per spam. Second, anyone can sue, including in small claims court. Third, you can sue the "beneficiary" of the spam, the business being advertised.
This should result in a tide of small suits against big companies. Any company that has some presence in California can be sued easily. Suing out-of-state companies may be possible; it's a "long-arm" statute.
Our local small claims court is putting in electronic filing. It may be possible to automate much of the process.
Nobody, even Lassiter and Jobs, really expected that Pixar would end up being a better and more original storyteller than Disney. Yet they did.
Most Disney work is derivative. From Snow White to Treasure Planet, the story came from elsewhere.
"Toy Story" and "Monsters, Inc" are entirely original. That's an achievement. Pixar has a good team. What makes them successful is their original concepts, not their All Renderman All the Time style. Monsters, Inc. would have worked as cel animation. Other technologies yield more realistic animation (see Stuart Little, which was done in Maya).
BitPass has a prominent "Certified by Entrust" logo on their web site. It means very little. Read their
certification practices statement, which guarantees almost nothing, disclaims liability for almost all cases, limits liability to $1000 per certificate (i.e. everybody scammed by one site),
and even calls for the "relying party" (the customer) to indemnify Entrust.
This is even weaker than Verisign's lower class of SSL certificate. Verisign at least requires a Dun and Bradstreet number.
There are far better seal programs, such as the classic Good Housekeeping Seal of Approval. That's an actual warranty. "If a product bearing the Seal proves to be defective within two years of purchase, Good Housekeeping will replace the product or refund the purchase price."
"Entrust" doesn't come anywhere near that.
Then there's the question of whether BitPass is a payment service or a reseller. iBill, for example, is a reseller. When you buy something through iBill, the actual "merchant" is iBill, and if you want a refund, you can get it through iBill's customer service operation. Getting it back from the site operator is iBill's problem, which is why they take a big cut and hold back payments for weeks.
BitPass doesn't seem to be set up that way.
BitPass is, in a sense, "selling money"
That may create problems. Credit card issuers don't allow merchants to "sell money"; that's a loan, which comes under banking laws. Also, the U.S. Government has a monopoly on money. Casinos in Las Vegas used to take each other's chips, but that was ruled to be a "currency" years ago, and they had to stop.
Worse, the BitPass site does not disclose the name and address of the business before asking for a credit card number. They've set things up so it's hard to get a refund. They don't disclose their refund policy. That's a criminal offense in California (B&P code 17538), where BitPass apparently is located. That's good for six months in jail.
Here's the law, which is very specific, so sleazy operators can't hide the required info and claim they comply.
(d) A vendor conducting business through the Internet or any other
electronic means of communication shall do all of the following when
the transaction involves a buyer located in this state:
(1) Before accepting any payment or processing any debit or credit
charge or funds transfer, the vendor shall disclose to the buyer in
writing or by electronic means of communication, such as e-mail or an
on-screen notice, the vendor's return and refund policy, the legal
name under which the business is conducted and, except as provided in
paragraph (3), the complete street address from which the business
is actually conducted.
(2) If the disclosure of the vendor's legal name and address
information required by this subdivision is made by on-screen notice,
all of the following shall apply:
(A) The disclosure of the legal name and address information shall
appear on any of the following: (i) the first screen displayed when
the vendor's electronic site is accessed, (ii) on the screen on
which goods or services are first offered, (iii) on the screen on
which a buyer may place the order for goods or services, (iv) on the
screen on which the buyer may enter payment information, such as a
credit card account number, or (v) for nonbrowser-based technologies,
in a manner that gives the user a reasonable opportunity to review
that information. The communication of that disclosure shall not be
structured to be smaller or less legible than the text of the offer
of the goods or services.
(3) The complete street address need not be disclosed as required
by paragraph (1) if the vendor utilizes
The textures are washed out and lack detail. Some rendering is wrong. The "dual chip" version is always displaying a frame behind. But it has a really l33t FPS rate on Quake.
Exactly. One consequence of this is that memory sizes on graphics boards haven't been growing as fast as they should, because that won't affect the FPS rate on older games.
Some time ago, I was talking to some NVidia developers about speeding up a bottleneck in the NVidia GEforce driver for Windows. The driver used to spinlock, using CPU time, if you did a wait for vertical blanking in OpenGL. This killed system performance if you were trying to do computation concurrent with graphics. But it didn't affect non-multithreaded games. NVidia was reluctant to fix it because they were afraid that giving up control for a context switch would hurt some FPS benchmarks. I pointed out that the "benchmarkers" turned off wait for VBLANK anyway, so that didn't matter. They agreed, fixed the driver to block, and you can now crunch while waiting for the display to retrace. Great for those of us who actually do 3D graphics.
I'd like to see a benchmark where you can crank the detail up and up, past one polygon per pixel, and watch the frame rate. That's what it's really about - crisp, sharp images. Cinematic work has had more polygons than pixels for years. Level of detail should only kick in at the subpixel level. Then it's right.
"Hop-On" has been hyping this for several years now. They've been wiped out by declining cell phone prices. Their plan was to charge huge per-minute rates ($0.25/minute was mentioned). But there's no reason for anybody to buy their crappy little box - you can get cheap prepaid cell phones from real companies at any 7-11. And yes, the prototype had a Nokia inside.
They don't even talk much about selling phones any more. They now sell "jeweled headsets" for other cell phones.
Stock price (HPON.PK): $0.10, down from an all time high of around $0.95.
Hundreds of people labor for months to design a graphics processor that can do real-time procedural shading of near-Renderman complexity, and the "reviewers" at Tom's Hardware focus on the heat sink.
Then there's this endless fascination with how many FPS you can get on some antique game. That's not what it's about. The question is how detailed a scene you can render at full frame rate.
6GB of memory can be installed, an unusual number. I would have expected a larger upper limit.
If you really need to break the 4GB barrier, 6GB seems low.
I'm glad I didn't get one of those. I have automated tools that access the SEC's EDGAR database of SEC filings. If they got random pages from some non-SEC site, that would break my database updates.
After this, I won't buy any Belkin product for any reason. Not even cables.
IBM's filings are superbly written...they have a good final edit team at work.
Yes, they do.
That's Cravath, the Big Grey Machine.
Cravath, Swaine and Moore are very good at major corporate litigation. They use large teams of lawyers, they are very thorough, they crosscheck everything, and they don't make mistakes. This is incredibly expensive, but, as Cravath puts it, it's for those "must-win" cases. IBM has used Cravath for decades.
Hand-waving and bombast doesn't work against
Cravath. Everything the opposition says and does is carefully entered into databases (Cravath pioneered the use of litigation support systems) analyzed, checked, investigated, rechecked, and answered in carefully drafted filings.
It's possible to win against Cravath, but not with a case as weak as SCO's. Making wild claims is completely the wrong approach.
With this precedent, going after spammers who are advertising spam-blocking software is going to be much easier.
That's a classic protection racket. In its heyday, the Mafia made much of its money that way, hassling small shopkeepers. The threat doesn't have to be explicit. Going around and telling people "something bad might happen to you if you don't pay us", combined with any act of harassment, is usually good enough for jail time.
Slashdot Mirror
As for transmission bikes, the old three-speed bikes had that decades ago. There was even a Borg-Warner 2-speed automatic tranmission for bikes.
Berg makes flexible plastic chain, and at one time they tried selling a version for bikes. It turned out to have compatibility problems with existing sprockets, but it could work with a sprocket redesign. Berg chain was used on the Gossamer Condor ultralight; it's lighter than steel chain. So that's something with potential.
NYC had to dumb down the tests, though, to avoid charges of racial discrimination. Now they're pass/fail, and those who pass are selected in sequence. They used to be truly competitive, resulting in overqualified low-level people.
Also in that set was the 1956 test for U.S. State Department Foreign Service Officer. "Which of the following phrases best expresses the idea that the United States supports the government with which you are dealing but will not support them militarily".
Of course, back then it took super programmmers to cram a complex graphical application into an 8086 running DOS.
You may be surprised how much of your personal information Mozilla has been quietly collecting by watching your web browsing. Has it captured your driver's license number or credit card numbers or mother's maiden name yet? Check and see.
Now they're in decline. Why would anyone want to acquire them, except as a distressed company? Their "content"? Yeah, right.
PL/I had compile-time programmability. That didn't help.
In LISP, macros became so bloated that Scheme had to be invented to strip the language down. But it was too late.
In the early days of UNIX, the M4 macro processor was popular. (It lives on as the horrible front end to Sendmail.)
Term-rewriting systems were a fad in the mid 1980s (remember Prolog?). Didn't help.
The trouble with compile-time programmability is lack of debuggability. At least with macro processors, you can look at the output. Combined with a language like C++, which has hiding without safety, it can only lead to trouble.
As for the examples, they show loop unwinding on an RS6000. The generated code is more appropriate for an earlier model PowerPC. The RS6000 has register renaming, so it's not necessary to use a different register for each successive operation to get instruction level parallelism.
Register renaming is what made loop unrolling obsolete. In the x86 world, register renaming came in with the Pentium Pro. For x86, it's essential if you want to get much instruction level paralleism, since there are so few registers. Once that worked, it was possible to get several iterations of the same loop going at the same time.
The downside of loop unrolling is code bloat, which leads to cache misses.
Up at the source level at which Blitz is working, the unrolling template has no idea of what's going on down at the machine level. Doing a machine-level optimization at the source level can well be a lose.
I used to do some heavy number-crunching involving a code generator that unwound big mechanical engineering problems into huge blocks of straight-line C code. In 1990, this was a clear win. By 1998, it was a clear lose.
The most impressive perversion of this ilk is the Blitz numeric library. This does loop unrolling by using the template library as a term-rewriting system. The resulting code is very complex, hard to debug, and of marginal value. Blindly unrollilng loops without understanding the target architecture at the instruction level is a lose on many modern superscalar machines. Newer machines tend to do loops faster than straight-line code.
Debugging compile-time processing in C++ is tough. You can't step through the process, you can't print anything, and the compiler doesn't provides any output about what's going on. Programming at compile time has a long, sordid history (LISP macros come to mind), and C++ is an inferior environment for it anyway.
If you're using a compiler which will develop templates in-line, decide if-statements at compile time, and discard unreachable code (which includes most modern compilers), it's better to write code which works that way, rather than use template specialization.
First, if SCO stalls much longer on discovery, Cravath will be in a good position to move for a dismissal. They might get it, too. Maybe even a dismissal with prejudice, so SCO can't refile, or summary judgement in IBM's favor.
Independent of this, it looks like IBM is gearing up for a securities-fraud counterclaim. Cravath has pointed out in legal filings that SCO has made statements publicly that are inconsistent with the positions they take in court. Ordinarily, that's OK. But when the stock price spikes and insiders are cashing out, that's not OK.
There's also the potential of a false-claim-of-copyright claim. That's rarely used, but here, it's clearly appropriate.
This is going to crank for a while, but unless SCO comes up with something a lot better than what they've shown so far, they're not going to win.
Verisign also handles wiretapping. If your phone is being wiretapped, Verisign reroutes all your calls (in and out) to a wiretapping center by altering the routing database. From the wiretapping center, the call is then routed to the destination. This allows both interception and, potentially, man-in-the-middle crypto attacks.
Some photographers are worth it. Look at Richard Avedon's work.
Talk to some models. It's a lousy job. The top 50 or so make real money. All the others make less than a mid-level programmer. Below the top 500 or so, it's a part-time job with a short career. There are thousands of actress/model/waitress types in LA.
As with many other things in 1970s computing, UNIVAC was way ahead.
Here's the real robot hall of fame, the Computer History Museum's robot collection. Many of the famous ones are there, including the Hopkins Beast and Shakey. They used to be on public display in Boston, but now they're in Mountain View, California. The Computer History Museum now has a new building, and is gradually setting up exhibits. Tours are available.
But so far, the fab-technology people have always caught up, fixed the defect problem, and made it possible to produce perfect parts with high yields. None of those techniques have been used much in production products.
Right now, fab technology is ahead of device physics. It's possible to fabricate smaller transistors than can be made to work. Power dissipation is more of a limit than line width. So at least on flat silicon, we don't need this yet.
This should result in a tide of small suits against big companies. Any company that has some presence in California can be sued easily. Suing out-of-state companies may be possible; it's a "long-arm" statute.
Our local small claims court is putting in electronic filing. It may be possible to automate much of the process.
Nobody, even Lassiter and Jobs, really expected that Pixar would end up being a better and more original storyteller than Disney. Yet they did. Most Disney work is derivative. From Snow White to Treasure Planet, the story came from elsewhere. "Toy Story" and "Monsters, Inc" are entirely original. That's an achievement. Pixar has a good team. What makes them successful is their original concepts, not their All Renderman All the Time style. Monsters, Inc. would have worked as cel animation. Other technologies yield more realistic animation (see Stuart Little, which was done in Maya).
This is even weaker than Verisign's lower class of SSL certificate. Verisign at least requires a Dun and Bradstreet number.
There are far better seal programs, such as the classic Good Housekeeping Seal of Approval. That's an actual warranty. "If a product bearing the Seal proves to be defective within two years of purchase, Good Housekeeping will replace the product or refund the purchase price." "Entrust" doesn't come anywhere near that.
Then there's the question of whether BitPass is a payment service or a reseller. iBill, for example, is a reseller. When you buy something through iBill, the actual "merchant" is iBill, and if you want a refund, you can get it through iBill's customer service operation. Getting it back from the site operator is iBill's problem, which is why they take a big cut and hold back payments for weeks.
BitPass doesn't seem to be set up that way. BitPass is, in a sense, "selling money" That may create problems. Credit card issuers don't allow merchants to "sell money"; that's a loan, which comes under banking laws. Also, the U.S. Government has a monopoly on money. Casinos in Las Vegas used to take each other's chips, but that was ruled to be a "currency" years ago, and they had to stop.
Worse, the BitPass site does not disclose the name and address of the business before asking for a credit card number. They've set things up so it's hard to get a refund. They don't disclose their refund policy. That's a criminal offense in California (B&P code 17538), where BitPass apparently is located. That's good for six months in jail. Here's the law, which is very specific, so sleazy operators can't hide the required info and claim they comply.
(1) Before accepting any payment or processing any debit or credit charge or funds transfer, the vendor shall disclose to the buyer in writing or by electronic means of communication, such as e-mail or an on-screen notice, the vendor's return and refund policy, the legal name under which the business is conducted and, except as provided in paragraph (3), the complete street address from which the business is actually conducted.
(2) If the disclosure of the vendor's legal name and address information required by this subdivision is made by on-screen notice, all of the following shall apply:
(A) The disclosure of the legal name and address information shall appear on any of the following: (i) the first screen displayed when the vendor's electronic site is accessed, (ii) on the screen on which goods or services are first offered, (iii) on the screen on which a buyer may place the order for goods or services, (iv) on the screen on which the buyer may enter payment information, such as a credit card account number, or (v) for nonbrowser-based technologies, in a manner that gives the user a reasonable opportunity to review that information. The communication of that disclosure shall not be structured to be smaller or less legible than the text of the offer of the goods or services.
(3) The complete street address need not be disclosed as required by paragraph (1) if the vendor utilizes
When a reviewer says it's going to be fixed next month, they're sucking up.
The textures are washed out and lack detail. Some rendering is wrong. The "dual chip" version is always displaying a frame behind. But it has a really l33t FPS rate on Quake.
Some time ago, I was talking to some NVidia developers about speeding up a bottleneck in the NVidia GEforce driver for Windows. The driver used to spinlock, using CPU time, if you did a wait for vertical blanking in OpenGL. This killed system performance if you were trying to do computation concurrent with graphics. But it didn't affect non-multithreaded games. NVidia was reluctant to fix it because they were afraid that giving up control for a context switch would hurt some FPS benchmarks. I pointed out that the "benchmarkers" turned off wait for VBLANK anyway, so that didn't matter. They agreed, fixed the driver to block, and you can now crunch while waiting for the display to retrace. Great for those of us who actually do 3D graphics.
I'd like to see a benchmark where you can crank the detail up and up, past one polygon per pixel, and watch the frame rate. That's what it's really about - crisp, sharp images. Cinematic work has had more polygons than pixels for years. Level of detail should only kick in at the subpixel level. Then it's right.
They don't even talk much about selling phones any more. They now sell "jeweled headsets" for other cell phones.
Stock price (HPON.PK): $0.10, down from an all time high of around $0.95.
Then there's this endless fascination with how many FPS you can get on some antique game. That's not what it's about. The question is how detailed a scene you can render at full frame rate.
6GB of memory can be installed, an unusual number. I would have expected a larger upper limit. If you really need to break the 4GB barrier, 6GB seems low.
I think we can finally write off the Inanium.
After this, I won't buy any Belkin product for any reason. Not even cables.
Yes, they do. That's Cravath, the Big Grey Machine.
Cravath, Swaine and Moore are very good at major corporate litigation. They use large teams of lawyers, they are very thorough, they crosscheck everything, and they don't make mistakes. This is incredibly expensive, but, as Cravath puts it, it's for those "must-win" cases. IBM has used Cravath for decades.
Hand-waving and bombast doesn't work against Cravath. Everything the opposition says and does is carefully entered into databases (Cravath pioneered the use of litigation support systems) analyzed, checked, investigated, rechecked, and answered in carefully drafted filings.
It's possible to win against Cravath, but not with a case as weak as SCO's. Making wild claims is completely the wrong approach.
That's a classic protection racket. In its heyday, the Mafia made much of its money that way, hassling small shopkeepers. The threat doesn't have to be explicit. Going around and telling people "something bad might happen to you if you don't pay us", combined with any act of harassment, is usually good enough for jail time.