There are archival quality CD blanks. They use phthalocyanine dyes, which require a slower writing rate but last longer. But the blanks are about $1.50 to $2.00 each, and are not widely available.
Mitsui claims that their new dye formulation for their DVD-R and DVD+R blanks has a >100 year life, but they don't offer any independent information to back that up.
There seems to be an effort by somebody to keep the price from dropping below 6.0. Look at the 5 day chart. Every time the price dips below 6.0, there's a buy to push it back up to 6, but no higher. Thursday's chart is striking in this respect. It looks like somebody had a limit order in at 6.0. This may be SCO's announced "stock buyback" program. It will be interesting to see the SEC filings for the next quarter, when we find out how much cash went into the buyback.
SCOX closed at 6.01 on Thursday and 5.99 on Friday. That does look like an effort to maintain the price.
This only works until SCO runs out of cash, of course.
The "National Cyber Security Partnership" has issued a new report on computer security. It focuses on how vendors can avoid responsibility for the defects in their products. The report suggests that the government weaken the Common Criteria for evaluating software security to conform to "commercial reality". The report suggests that the Government, at taxpayer expense, develop "code scanning" tools usable on existing software, thus deferring any action by vendors. There's no suggestion that vendors be held responsible for security flaws, or that any major changes, either technical or in business models. are required by vendors.
Virus authors have nothing to worry about from this security group.
Some excerpts:
While strong out-of-the-box security configurations are preferred, it is recognized that updating existing products to
comply with this requirement can be costly, time-consuming and can result in various incompatibilities with current
and supported versions of the product. As a result, it may not be possible for a vendor to transition a product to a
more secure out-of-the-box state for several years, depending on product release cycles....
In conjunction with the above recommendations, the requirement for medium or higher assurance
evaluations (Evaluation Assurance Level 4+ [EAL4+]) for commercial products should be dropped, since the stated
reason for higher assurance evaluations by the proponents is the ability to do vulnerability analysis. Higher
assurance evaluations for commercial software impose a cost burden that even the largest IT vendors cannot bear or
should not bear; they do not substantially improve product security, but may result in vendors paying multiple times
for the same evaluation in different markets. Furthermore, finding faults in software that has already shipped is far
more expensive and less effective than giving vendors the tools to be used during the development process....
In order to promote the evaluation of more products, the U.S. Government should help offset the
expenses of CC evaluation through research and development tax credits or paying part of the evaluation costs.
If the rules changed to the DMA 4 pillars, how many ISPs and other organizations would continue to query bonded sender? This program would die a quick death.
You know they will try to delay it again, and again, and again.............
SCO has paid a price for that delay. SCO had to abandon the trade secret claim. SCO had to narrow their copyright claims. They've already had to back off quite a bit. SCO is not gaining by the delays; they're losing.
AutoZone has a motion pending to put their case on hold until the IBM case is decided. They cite SCO's stalling in the IBM case as a reason to do this, and the court in the AutoZone case is likely to agree. Especially since SCO asked the court in the Red Hat case to stall that case until the IBM case is decided, and that court agreed.
If that happens, all further SCO-initiated lawsuits will go on hold until IBM is done with them. Further SCO-initiated lawsuits are then an empty threat.
That's my point. After two decades of buffer overflows, it's time to fix the problem. It's going to cost. It's going to hurt. It has to be done, like Y2K fixes.
The trouble, though, is that IronPort/BondedSender reserves the right to change the rules at any time. Already, bulk mailers are complaining the rules are too restrictive. Once they have all the backdoors in place at major ISPs, they can change the rules.
A likely change would be to embrace the Direct Marketing Association's "Four Pillars of Responsible E-Mail Marketing".. That's opt-out, not opt-in. And it's "narrow opt-out"; you may have to opt out for each "line of business" of each spammer separately. Once
for Viagra, once for refinancing, once for toner
cartridges...
My point is that you don't want to blindly let through everything Ironport sends. You might give them some credit in the spam filters, but don't just open a hole.
It's a slow week for SCOX.
It's been trading around 6.25 +- 0.25 for the last week. Volume is down. Over the last six months, the stock has tanked. It started the year around 18. But this week is slow.
The market is losing interest in SCOX. It's clear now that there's no big near-term win there.
It's hard to get excited about a press release from a lobbyist from a trade association, especially when it doesn't announce any action.
But it's good to have statements like that, because it discourages Congressional action. Recall that SCO was lobbying Congress at one point. With IBM, Damlier-Chrysler, Utah's Novell, Goldman Sachs, and the National Retail Federation against SCO, Congress isn't going to do anything stupid.
The real action is in the SCO vs IBM lawsuit, where SCO is not doing well. SCO has narrowed their copyright claim. SCO had a deadline coming up on the discovery front, where they have to disclose the "infringing code". They're close to the "put up or shut up" point in that case.
They've stalled and stalled, but it didn't work. One motion at a time, IBM has whittled away at SCO's claims. The trade secret claim is gone. The copyright claims are steadily shrinking. The claim that the GPL is "unconstitutional" is gone.
Meanwhile, IBM's claims against SCO threaten SCO's remaining cash.
Stop using languages/tools that allow you have buffer overflows in code. That'll cut out 90% of critical updates in one swoop.
Yes. I've been trying to get the C++ committee to tighten up that language for years, with little success. It's time to get more serious about this, and apply pressure via ANSI (which is supposed to insure that standards are safe) and the Department of
Homeland Security's National Cyber Security Division. Like it or not, we need to go to full subscript checking for anything that could possibly be exploited. The resulting 10-20% performance hit is minor compared to the costs of dealing with these attacks.
I've sent this to the C++ committee:
After the damage caused by the Sasser worm, the latest in a
long series of buffer overflow exploits, perhaps the designed-in
lack of safety in C++ should be reconsidered.
The Sasser worm exploits a buffer overflow in Microsoft's
LSASS service, which is, apparently, written in C++.
Perhaps more weight should be given by the Standards Committee
to tightening up C++ and making it a safer language.
The Committee has consistently rejected most suggestions
which tighten up the language, usually on the grounds that they
would impact existing code or prevent some dangerous but
valid code from being used.
It is now appropriate to ask ANSI, and the Department of
Homeland Security's National Cyber Security Division, to
reevaluate the C++ committee's priorities in the
light of the documented and substantial damage caused
by weak safety features of the language. Whether the
committee should be permitted to promulgate unsafe
technologies with ANSI approval must be seriously
questioned at this point.
That will probably be ineffective. The appropriate forum will probably be Congressional hearings on computer security, which were threatened last year after the SOBIG virus, and are likely to happen this year.
IronPort wants you to install a hole to let their stuff through. For SpamAssassin, for example,
they want you to put in
header RCVD_IN_BONDEDSENDER eval:check_rbl('relay', 'sa.bondedsender.org.')
describe RCVD_IN_BONDEDSENDER Received via a whitelisted Bonded Sender address
score RCVD_IN_BONDEDSENDER -100.000
Note that "-100.000". That says "accept this, even if it looks like spam". You might want to use, say, "-3.0" instead. Give them a little credit, but don't open the floodgates.
Watch for spam with the "RCVD_IN_BONDEDSENDER" flag in the X-Spam-Status header line. You might want to have Mozilla (I assume Slashdot readers
aren't using Outlook) move such messages into a "Bonded Sender" folder. That lets you watch what they're sending.
As soon as you find a real spam passed by BondedSender, please post it to NANAE.
Where did that "$20,000 bond" figure come from?
BondedSender's price list starts at $200, for nonprofits. The "bond" for sending 5,000,000 spams is only $1000. And for $2000, you get to send 50,000,000 spams. Per month.
It's getting hard to get good low-end phones. Ones that are small, indestructable, easy to use, and with really long battery life.
Motorola came close for a while, but they seem to have had a falling out with Sprint.
There are still interesting things to be done in the phone space other than more keyboard-oriented features. Active background noise cancellation. Waterproofing. Better voice recognition for voice dialing. An interface with directory assistance that puts numbers you're given into your phone's memory.
Or new form factors. I'm surprised we haven't seen the earring/pendant/belt wearable version for teenage girls.
It includes such information as what domains are
entrusted to authenticate logon attempts, who has permission to access
the system and how (interactive, network, and service logons), who is
assigned which privileges, and what kind of security auditing is to be
performed. The Lsass policy database also stores "secrets" that
include logon information used for cached domain logons and Win32
service user-account logons.
LASSS is the security policy manager for NT and XP.
If that's been compromised, you have to assume it was used to put in a back door. Or to transmit password-type "secrets" to some external site. It may also have changed the logs to hide it. You've got to rebuild and reexamine the entire security policy database. Passwords may have been compromised. Local shares may be exposed to outside attack.
If this thing actually worked, they'd be selling it for applications that really need steerable directionality, like radars and satellite receivers.
If they're selling it for "homeland security", it's probably not that good.
The "war on terror" is turning into a pork program.
The era of big profits on CPUs is over. They're a commodity now. That's killing Intel.
There's a big change coming to the CPU industry. One of the major graphics chip manufacturers is about to put an x86 CPU in their chipset. This cuts out the CPU vendors entirely.
How did open source software end up costing $60 per year per machine? Something has gone wrong here.
How did a situation get created where you can't make copies of open source software for free? Apparently, all you have to do is "contaminate" the distribution with some proprietary software, and you get to crank up the price.
What would it take to replace the proprietary parts of Red Hat's distro with open source software?
Selling support is fine, but Red Hat is now basically a Microsoft competitor. Red Hat's pricing is roughly comparable to Microsoft's now.
While this thing really does exist, Holosonics seems to have problems getting the product out. They announced a new version at CES back in January, but it's still not on their web site.
Once they get it working and get the price down, there are good applications. PC speakers for office environments. Audio at trade shows. Anywhere there are many audio sources that you don't want to interfere.
It's not clear what the holdup is. It doesn't seem that complicated.
I've always had some stability issues with spring/damper systems - they seem to me to be a little sensitive to floating point errors when you create very stiff springs.
Yes, they are, and those errors must be detected and bounded. But it can all work. Not easily.
Treating contact points as a joint handles the easy cases rapidly. But sliding contact is a problem.
Doing spring/damper in real time for a complex world would probably take more CPU than is presently available, but if you were doing a two-person fighter and wanted really good physics, it could work.
I always wanted to do more in the control area for physically-based character animation, but assembling mocap segments works well enough for most game applications. Besides, if you have physically realistic characters, they have to have human-quality reflexes. Even controlling legged running is tough, let alone martial arts.
Because legged locomotion is dominated by sliding contact problems, I've been interested in getting better physical simulation techniques in that area.
There's been some recent work reported at GDC on Verlet integration for implicit integration in a physics engine. That may lead to faster spring/damper systems. See the 2004 GDC proceedings. I tried several implicit integrators a few years ago, and they worked, but the convergence time for the nonlinear solver for a single big step was worse than the time to do many little steps with explicit RK4 integration.
Recomputing the Jacobian by differencing is too expensive, and is needed too frequently. Maybe if you had analytical Jacobians...
Somebody needs to crack that performance problem.
But you don't want to tackle that one when you have a game to ship.
That's what commercial physics engines like Havok are for,
The Havok engine on the Playstation 2 reportedly uses the vector processors, so special purpose hardware is already being used.
Massive parallelism is helpful to a physics engine,
as are lots of fast FPUs. (Preferably double precision. Single precision in a physics engine requires workarounds for the low precision, if the world is at all big. You lose precision when far from the origin. The PS2 has single precision floating point only, which is a headache.) You do lots of 4x4 matrix multiplies, so the same kind of hardware that appears in the geometry-acceleration part of a GPU is helpful. There's not much use for the back end of a GPU, with the frame buffers, Z buffers, and fill engine.
The hardware requirements for a physics engine look much like those for a number-crunching supercomputer. That's not surprising; the calculations are quite similar.
Amusingly. the biggest supercomputer today, the Earth Simulator in Japan, has a architecture that looks vaguely similar to a PS2.
I'm John Nagle, owner of Animats, and you can reach me through the addresses on the Animats web site.
If you have to handle the hard cases, like multiple simultaneous sliding contacts, the Baraff-type LCP solutions don't really work too well, or at least they didn't a few years ago.
I realize there's been some progress. I prefer spring/damper simulators, because you can handle frictional contacts right and you don't have the zero-time bounces (the "boink problem") of impulse/constraint systems. The CPU load is higher, but that's less of a problem than it used to be.
A good test of a physics system is the spinning top. That's easy to set up. The base should roll around a little (it has a nonzero diameter), the top should precess, it should recover from small disturbing impacts, and over time, the speed of the top should slow. Just like a real top. If it doesn't behave like that, something is broken.
I'm the inventor of "ragdoll physics".
More of my physics videos. Those are from work done in 1996-1998. (The videos are overcompressed; everybody had less bandwidth back then.)
The difference between "sort of works" and "works as well as that" is non-trivial. That's why I collect royalties on the technology.
Slashdot Mirror
Mitsui claims that their new dye formulation for their DVD-R and DVD+R blanks has a >100 year life, but they don't offer any independent information to back that up.
SCOX closed at 6.01 on Thursday and 5.99 on Friday. That does look like an effort to maintain the price.
This only works until SCO runs out of cash, of course.
Notice the part where they ask for a tax break.
Virus authors have nothing to worry about from this security group.
Some excerpts:
-
While strong out-of-the-box security configurations are preferred, it is recognized that updating existing products to
comply with this requirement can be costly, time-consuming and can result in various incompatibilities with current
and supported versions of the product. As a result, it may not be possible for a vendor to transition a product to a
more secure out-of-the-box state for several years, depending on product release cycles.
...
Whose side are these guys on?In conjunction with the above recommendations, the requirement for medium or higher assurance evaluations (Evaluation Assurance Level 4+ [EAL4+]) for commercial products should be dropped, since the stated reason for higher assurance evaluations by the proponents is the ability to do vulnerability analysis. Higher assurance evaluations for commercial software impose a cost burden that even the largest IT vendors cannot bear or should not bear; they do not substantially improve product security, but may result in vendors paying multiple times for the same evaluation in different markets. Furthermore, finding faults in software that has already shipped is far more expensive and less effective than giving vendors the tools to be used during the development process. ...
In order to promote the evaluation of more products, the U.S. Government should help offset the expenses of CC evaluation through research and development tax credits or paying part of the evaluation costs.
I hope you're right. But this involves Microsoft.
You can't tune the thing while running? That is so lame.
And, sure enough, there's a known, exploitable buffer overflow in Microsoft's RLE image decoder.
SCO has paid a price for that delay. SCO had to abandon the trade secret claim. SCO had to narrow their copyright claims. They've already had to back off quite a bit. SCO is not gaining by the delays; they're losing.
AutoZone has a motion pending to put their case on hold until the IBM case is decided. They cite SCO's stalling in the IBM case as a reason to do this, and the court in the AutoZone case is likely to agree. Especially since SCO asked the court in the Red Hat case to stall that case until the IBM case is decided, and that court agreed.
If that happens, all further SCO-initiated lawsuits will go on hold until IBM is done with them. Further SCO-initiated lawsuits are then an empty threat.
That's my point. After two decades of buffer overflows, it's time to fix the problem. It's going to cost. It's going to hurt. It has to be done, like Y2K fixes.
A likely change would be to embrace the Direct Marketing Association's "Four Pillars of Responsible E-Mail Marketing".. That's opt-out, not opt-in. And it's "narrow opt-out"; you may have to opt out for each "line of business" of each spammer separately. Once for Viagra, once for refinancing, once for toner cartridges...
My point is that you don't want to blindly let through everything Ironport sends. You might give them some credit in the spam filters, but don't just open a hole.
The market is losing interest in SCOX. It's clear now that there's no big near-term win there.
It's hard to get excited about a press release from a lobbyist from a trade association, especially when it doesn't announce any action. But it's good to have statements like that, because it discourages Congressional action. Recall that SCO was lobbying Congress at one point. With IBM, Damlier-Chrysler, Utah's Novell, Goldman Sachs, and the National Retail Federation against SCO, Congress isn't going to do anything stupid.
The real action is in the SCO vs IBM lawsuit, where SCO is not doing well. SCO has narrowed their copyright claim. SCO had a deadline coming up on the discovery front, where they have to disclose the "infringing code". They're close to the "put up or shut up" point in that case. They've stalled and stalled, but it didn't work. One motion at a time, IBM has whittled away at SCO's claims. The trade secret claim is gone. The copyright claims are steadily shrinking. The claim that the GPL is "unconstitutional" is gone. Meanwhile, IBM's claims against SCO threaten SCO's remaining cash.
Yes. I've been trying to get the C++ committee to tighten up that language for years, with little success. It's time to get more serious about this, and apply pressure via ANSI (which is supposed to insure that standards are safe) and the Department of Homeland Security's National Cyber Security Division. Like it or not, we need to go to full subscript checking for anything that could possibly be exploited. The resulting 10-20% performance hit is minor compared to the costs of dealing with these attacks.
I've sent this to the C++ committee:
The Sasser worm exploits a buffer overflow in Microsoft's LSASS service, which is, apparently, written in C++.
Perhaps more weight should be given by the Standards Committee to tightening up C++ and making it a safer language. The Committee has consistently rejected most suggestions which tighten up the language, usually on the grounds that they would impact existing code or prevent some dangerous but valid code from being used.
It is now appropriate to ask ANSI, and the Department of Homeland Security's National Cyber Security Division, to reevaluate the C++ committee's priorities in the light of the documented and substantial damage caused by weak safety features of the language. Whether the committee should be permitted to promulgate unsafe technologies with ANSI approval must be seriously questioned at this point.
That will probably be ineffective. The appropriate forum will probably be Congressional hearings on computer security, which were threatened last year after the SOBIG virus, and are likely to happen this year.
describe RCVD_IN_BONDEDSENDER Received via a whitelisted Bonded Sender address
score RCVD_IN_BONDEDSENDER -100.000
Note that "-100.000". That says "accept this, even if it looks like spam". You might want to use, say, "-3.0" instead. Give them a little credit, but don't open the floodgates.
Watch for spam with the "RCVD_IN_BONDEDSENDER" flag in the X-Spam-Status header line. You might want to have Mozilla (I assume Slashdot readers aren't using Outlook) move such messages into a "Bonded Sender" folder. That lets you watch what they're sending.
As soon as you find a real spam passed by BondedSender, please post it to NANAE.
Where did that "$20,000 bond" figure come from? BondedSender's price list starts at $200, for nonprofits. The "bond" for sending 5,000,000 spams is only $1000. And for $2000, you get to send 50,000,000 spams. Per month.
Motorola came close for a while, but they seem to have had a falling out with Sprint.
There are still interesting things to be done in the phone space other than more keyboard-oriented features. Active background noise cancellation. Waterproofing. Better voice recognition for voice dialing. An interface with directory assistance that puts numbers you're given into your phone's memory.
Or new form factors. I'm surprised we haven't seen the earring/pendant/belt wearable version for teenage girls.
LASSS is the security policy manager for NT and XP. If that's been compromised, you have to assume it was used to put in a back door. Or to transmit password-type "secrets" to some external site. It may also have changed the logs to hide it. You've got to rebuild and reexamine the entire security policy database. Passwords may have been compromised. Local shares may be exposed to outside attack.
The "war on terror" is turning into a pork program.
There's a big change coming to the CPU industry. One of the major graphics chip manufacturers is about to put an x86 CPU in their chipset. This cuts out the CPU vendors entirely.
What would it take to replace the proprietary parts of Red Hat's distro with open source software?
Selling support is fine, but Red Hat is now basically a Microsoft competitor. Red Hat's pricing is roughly comparable to Microsoft's now.
Once they get it working and get the price down, there are good applications. PC speakers for office environments. Audio at trade shows. Anywhere there are many audio sources that you don't want to interfere.
It's not clear what the holdup is. It doesn't seem that complicated.
Yes, they are, and those errors must be detected and bounded. But it can all work. Not easily.
Treating contact points as a joint handles the easy cases rapidly. But sliding contact is a problem.
Doing spring/damper in real time for a complex world would probably take more CPU than is presently available, but if you were doing a two-person fighter and wanted really good physics, it could work.
I always wanted to do more in the control area for physically-based character animation, but assembling mocap segments works well enough for most game applications. Besides, if you have physically realistic characters, they have to have human-quality reflexes. Even controlling legged running is tough, let alone martial arts. Because legged locomotion is dominated by sliding contact problems, I've been interested in getting better physical simulation techniques in that area.
There's been some recent work reported at GDC on Verlet integration for implicit integration in a physics engine. That may lead to faster spring/damper systems. See the 2004 GDC proceedings. I tried several implicit integrators a few years ago, and they worked, but the convergence time for the nonlinear solver for a single big step was worse than the time to do many little steps with explicit RK4 integration. Recomputing the Jacobian by differencing is too expensive, and is needed too frequently. Maybe if you had analytical Jacobians... Somebody needs to crack that performance problem. But you don't want to tackle that one when you have a game to ship.
For that "thumpa, thumpa thumpa" subwoofer effect, there's the Aura Interactor chest-mounted subwoofer.
Massive parallelism is helpful to a physics engine, as are lots of fast FPUs. (Preferably double precision. Single precision in a physics engine requires workarounds for the low precision, if the world is at all big. You lose precision when far from the origin. The PS2 has single precision floating point only, which is a headache.) You do lots of 4x4 matrix multiplies, so the same kind of hardware that appears in the geometry-acceleration part of a GPU is helpful. There's not much use for the back end of a GPU, with the frame buffers, Z buffers, and fill engine.
The hardware requirements for a physics engine look much like those for a number-crunching supercomputer. That's not surprising; the calculations are quite similar. Amusingly. the biggest supercomputer today, the Earth Simulator in Japan, has a architecture that looks vaguely similar to a PS2.
If you have to handle the hard cases, like multiple simultaneous sliding contacts, the Baraff-type LCP solutions don't really work too well, or at least they didn't a few years ago. I realize there's been some progress. I prefer spring/damper simulators, because you can handle frictional contacts right and you don't have the zero-time bounces (the "boink problem") of impulse/constraint systems. The CPU load is higher, but that's less of a problem than it used to be.
A good test of a physics system is the spinning top. That's easy to set up. The base should roll around a little (it has a nonzero diameter), the top should precess, it should recover from small disturbing impacts, and over time, the speed of the top should slow. Just like a real top. If it doesn't behave like that, something is broken.
I'm the inventor of "ragdoll physics". More of my physics videos. Those are from work done in 1996-1998. (The videos are overcompressed; everybody had less bandwidth back then.)
The difference between "sort of works" and "works as well as that" is non-trivial. That's why I collect royalties on the technology.